<div dir="ltr">Hi, thanks for answering so quickly.<div><br></div><div style>You are right, we should not go so far as to implement a conversion from strong to weak ETags. </div><div style>And alo, Last-Modified header could be preferable. </div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>So I would not say that the Last-Modified header covers all cases that ETag does.</div><div style><br></div><div style>Instead of stripping all ETags, I would propose to only strip strong ETags.</div>
<div style><br></div><div style>According to the spec: <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3">http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3</a> a weak ETag is perfectly fine for validating semantic equivalence. Just not for range requests.</div>
<div style><br></div><div style>So by adding something like:</div><div style><br></div><div style>if (<font color="#444444" face="arial, sans-serif"><span style="line-height:16px">is_strong_etag(r)) {</span></font></div><div style>
  <span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px">ngx_http_clear_etag(r)</span></div><div style>} </div><div style><br></div><div style>We would allow applications to set weak Etags for caching.</div>
<div style><br></div><div style><br></div><div style><br></div><div style> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 16, 2013 at 4:08 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div><div class="h5"><br>
On Sat, Jun 15, 2013 at 02:58:33PM +0200, Matthijs Langenberg wrote:<br>
<br>
> I am serving dynamic requests behind the Nginx HTTP server. HTTP requests<br>
> are mostly from mobile HTTP clients. That's is why I care about two things.<br>
><br>
> 1. Do not send the same representation twice: Use ETag caching mechanism.<br>
> 2. Make better us of available bandwidth: Use Accept-Encoding HTTP<br>
> compression.<br>
><br>
> Today I noticed that these two don't match. My application sets the ETag<br>
> header in the response, but when I set the 'Accept-Encoding: gzip' in the<br>
> request header, nginx clears the ETag header when gzipping on-the-fly.<br>
><br>
> I understand why this is: If two responses have the same ETag, their bodies<br>
> should be byte-for-byte comparable. When the content is gzipped, and<br>
> actually modified, this is of course not the case. The gzipped response is<br>
> not equal to the non-gzipped response.<br>
><br>
> That's why there are two ETag validation mechanisms. A strong validation,<br>
> used in case of byte-for-byte comparable responses, and a weak validation,<br>
> to indicate semantic equivalency.<br>
><br>
> In the case of weak validation an ETag would look like:<br>
> ETag: W/"123456789"<br>
><br>
> Why is Nginx stripping weak ETag validators in its gzip filter?<br>
<br>
</div></div>Just stripping ETags are easier than converting them to weak<br>
etags (and implementing weak etags support various places).<br>
<br>
On the other hand, relevant caching functionality is still here<br>
with Last-Modified cache validator.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</font></span></blockquote></div><br></div>