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 <mdounin@mdounin.ru> 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
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx