etag not set on gzip-encoded resources in 1.3.6 #70
Comments
New versions of nginx have a call to While nginx would be right to remove a strong etag (because it's gzip-compressing and so changing bytes) I think it should not be removing a weak one. On the other hand, these resource are all cacheable for a year and have a content-hash in the url, so the etag shouldn't be needed. Looking at the mod_pagespeed source and talking to people here it's to work around an image caching bug with IE8. It's possible that this only applies if we also send a |
Test page:
Serves with headers:
These are identical to what mod_pagespeed gives you, except that would contain an Etag:
In IE8, through webpagetest, we get:
which shows that IE8's caching worked properly. Here's the same image loaded directly from mod_pagespeed.com, served with Etag:
Caching also works, which is what we would expect. This suggests to me that we can remove the Etag-setting from mod_pagespeed and remove checking for it from the system test. |
I've taken this up internally; on hold for now. |
|
Another solution would be to add a new filter that runs as late as possible, after gzipping, and ads etags for .pagespeed. resources. |
working on this one |
Fixed by #340, released in 1.5.27.3 |
I'm still getting this problem. Using nginx-extras from dotdeb. |
To reproduce:
vs:
Note that the latter has
Etag: W/"0"
while the former does not.This fails in nginx 1.3.6 but not in 1.2.4.
The text was updated successfully, but these errors were encountered: