weak etags #1178

tj opened this Issue Jun 15, 2012 · 7 comments


None yet

4 participants

tj commented Jun 15, 2012

currently sending them as strong validators, which they are not

moll commented Sep 4, 2013

Given that you CRC the body currently, that is the strong version.

tj commented Sep 7, 2013

we don't include header fields, that's the problem ATM


do you know which headers we have to include? can't find anything on that. i'm guessing:

  • content-length
  • content-language
  • content-type

These are the entity header fields: http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html

Which responses are we thinking about sending this for? All responses where we know the full response upfront? Why not strong etags? Also, we might want to be smarter and see if the person set no-cache for cache control and then not do etags. Not sure if that is a good idea or not but it might be worth thinking about.


What is the status of this? Was this about the headers we send during res.render or some other api call?


Just .send. IMO it's not worth it, especially if no one complains


i'm going to close this for now. let's revisit if someone actually complains. the only instances i think this would be a problem is:

  • if people send the same content with different content headers, though this should be solved by doing content negotiation before you do any "fresh" checking
  • crc collisions, but we can just change the algorithm to sha or something
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment