weak etags #1178

Closed
tj opened this Issue Jun 15, 2012 · 7 comments

Projects

None yet

4 participants

@tj
Owner
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.

Owner
tj commented Sep 7, 2013

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

Member

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

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

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.

Contributor

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

Member

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

Member

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