Hi, thanks for answering so quickly. You are right, we should not go so far as to implement a conversion from strong to weak ETags. And alo, Last-Modified header could be preferable.
Wen dynamic content is generated, setting a Last-Modified header requires inside knowledge from the app server. ETags are much simpler, as it's often implemented as an md5 hash of the response body. A (Ruby) app server can easily add an ETag to all responses. Setting a Last-Modified header is different per request, depending on what dynamic resource is generated. So I would not say that the Last-Modified header covers all cases that ETag does. Instead of stripping all ETags, I would propose to only strip strong ETags. According to the spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3 a weak ETag is perfectly fine for validating semantic equivalence. Just not for range requests. So by adding something like: if (is_strong_etag(r)) { ngx_http_clear_etag(r) } We would allow applications to set weak Etags for caching. On Sun, Jun 16, 2013 at 4:08 AM, Maxim Dounin <[email protected]> wrote: > Hello! > > On Sat, Jun 15, 2013 at 02:58:33PM +0200, Matthijs Langenberg wrote: > > > I am serving dynamic requests behind the Nginx HTTP server. HTTP requests > > are mostly from mobile HTTP clients. That's is why I care about two > things. > > > > 1. Do not send the same representation twice: Use ETag caching mechanism. > > 2. Make better us of available bandwidth: Use Accept-Encoding HTTP > > compression. > > > > Today I noticed that these two don't match. My application sets the ETag > > header in the response, but when I set the 'Accept-Encoding: gzip' in the > > request header, nginx clears the ETag header when gzipping on-the-fly. > > > > I understand why this is: If two responses have the same ETag, their > bodies > > should be byte-for-byte comparable. When the content is gzipped, and > > actually modified, this is of course not the case. The gzipped response > is > > not equal to the non-gzipped response. > > > > That's why there are two ETag validation mechanisms. A strong validation, > > used in case of byte-for-byte comparable responses, and a weak > validation, > > to indicate semantic equivalency. > > > > In the case of weak validation an ETag would look like: > > ETag: W/"123456789" > > > > Why is Nginx stripping weak ETag validators in its gzip filter? > > Just stripping ETags are easier than converting them to weak > etags (and implementing weak etags support various places). > > On the other hand, relevant caching functionality is still here > with Last-Modified cache validator. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
