Express: Option to disable ETag for certain routes?

Created on 16 Dec 2014 · 9Comments · Source: expressjs/express

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".

enhancement

Source

danielgindi

👍12

Most helpful comment

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.

dougwilson on 16 Dec 2014

👍9 🎉2

All 9 comments

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.

dougwilson on 16 Dec 2014

👍9 🎉2

oo this is a nice trick :+1:

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

danielgindi on 16 Dec 2014

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. :)

dougwilson on 16 Dec 2014

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

danielgindi on 16 Dec 2014

2473

danielgindi on 16 Dec 2014

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 :)

dougwilson on 9 Jan 2015

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?

danielgindi on 9 Jan 2015

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 :)

dougwilson on 9 Jan 2015

❤1 👍1

Related to #2524