Skip to content

why strip out etag, last-modified headers? #28

6a68 opened this Issue Feb 6, 2013 · 2 comments

3 participants

Mozilla member
6a68 commented Feb 6, 2013

Looking at this line:

I don't understand why we'd remove ETag or Last-Modified headers. My read of the RFC is that, if the max-age is in the future, the cached copy will be used; if the max-age has elapsed, the Last-Modified or ETag values could be used to send a conditional-GET, so the server could still save bandwidth by returning a 304.

Are there implementation bugs of which I'm unaware?

Mozilla member

@6a68 - +1 your suggestion is common practice that I think we should make use of. The URL will be updated if the resource changes, and a conditional GET will save a few bytes once the cache does expire.

Mozilla member
ozten commented Feb 8, 2013

My memory is super fuzzy, but I remember other middleware trying to manage cache headers causing us issues. I think the intent is if you use connect-cachify you want to disable other codepaths from trying to do cache control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.