Option to disable ETag for certain routes?

[danielgindi]

There's a need to disable ETag for certain routes, where it is a GET but the data may still change between requests - and it is mandatory to have no caching on it.

Currently the ETag processing is done after the user's code for the response, so there's no way to remove it after express has added it.

Now if we add a Cache-Control: no-store, the client will surely ignore the ETag, but then the ETag is generated for nothing, and it's an extra CRC or MD5 call which can be spared.

So I think there's a need to make the ETag conditional also on the existence of a "no-store".

[dougwilson]

oo, I think we can definitely make the ETag generation skip if there is a certain Cache-Control header for sure.

As for if you need something immediately, you can use this little bit of code in your route (I won't skip the actual ETag generation, but at least the header won't exist):

var onHeaders = require('on-headers')

function myRoute(req, res) {
  scrubETag(res)
  // do the rest
  res.send('something')
}

function scrubETag(res) {
  onHeaders(res, function () {
    this.removeHeader('ETag')
  })
}

In general, this is fitting into a general theme that has been building up: people want to be able to override app settings on a per-request basis.

[danielgindi]

oo this is a nice trick :+1:

Are you going to add the Cache-Control condition or should I make a pull request?

[dougwilson]

Are you going to add the Cache-Control condition or should I make a pull request?

I think it's a great idea :) I do want to consult some RFCs just to verify that it is the right behavior to have embedded, but feel free to make a PR. :)

[danielgindi]

I'd say "don't bother, I've already done that", but that would be irresponsible of you ;-)

[danielgindi]

#2473

[dougwilson]

So the PR has been rejected, because it turned out that bit about no-cache was just an assumption; browsers still consult the ETag and make conditional requests, even with Cache-Control: no-cache so it doesn't make sense for Express to not add it to those responses.

As for you being able to control the ETag on a per-response/per-route basis, that's still a valid request :)

[danielgindi]

Yeah it seems to be more complicated... From further reading a combination of no-store no-cache restricts the browser more strictly, but it is a more complicated case to detect as there are many ways in which the combination can be specified.

Any ideas on how to implement ETag control on a per request basis?

[dougwilson]

Any ideas on how to implement ETag control on a per request basis?

It's not easy, but I'm working on it :) We basically want you to be able to override all the different app settings on a per-route/per-request basis, and the etag setting would of course be one :)

[tunniclm]

Related to #2524

[JC3]

@dougwilson

Is it possible to do this in express 4.18.1 or is this still an open FR?

If it's not possible, is the kludge (no judgment, haha) above in https://github.com/expressjs/express/issues/2472#issuecomment-67186349 still valid?

[JC3]

Btw, dunno how valid this suggestion is but if you're still trying to think of a way to implement it, maybe a more generic approach could be to let routes accept overrides of certain app settings, and internally drop those overrides in over the actual settings where possible when processing that route. Then users could set an etag app setting override for the route, and as a bonus side-effect it might open up a lot of other nice per-route settings.