|
When I used web-sniffer.net and disabled 'Accept-Encoding: gzip' it worked. I was also able to reproduce this with curl, So it appears to be based on client settings and not the server. Based on this observation I found a blog post which explains this, """ The issue was discussed over several forum threads and trackers. It appeared that Nginx deliberately strips ETags once gzip is applied, The motivation behind was that ETag should serve as a byte-accurate comparison, and since the result of gzip is not guaranteed to be identical under different configurations, ETag is no longer a strong validator and Nginx decided that it was simpler to remove it as opposed to converting it to a weak one. """ So, since Etag is essentially meaningless for gzip-encoded responses, Nginx strips it by design answered 03 Sep '15, 02:33 johns ♦♦ This should be fixed in the version 1.7 of Nginx: https://github.com/nulab/nginx-gzip-filter-allow-weak-etag-patch """"Nginx gzip filter module removes ETag every time gzip compression being applied whether the ETag is strong or weak. However, a weak ETag validator doesn't require that the resources to be compared are byte-for-byte identical. Hence a weak ETag header should be kept during gzip compression. Actually the latest version of nginx (1.7.x) has ETag downgrade functionality instead of clearing all ETag""""
(03 Sep '15, 08:34)
fra_t
Yes, the design decisions were changed in a later version of Nginx, but it's not a bug (per se) in Nginx 1.4, which your server runs. When Nginx is upgraded in the future to 1.7+, then this behavior will change automatically. Since all requests go through the front-end Nginx, there's no workaround to allow weak ETag support. I've created an internal ticket for our system administration team to consider upgrading Nginx to 1.7 or later per your request, but there needs to be enough interest to justify the change. If others need weak ETag support (or other Nginx 1.5+ features), please leave comments with a description below.
(03 Sep '15, 09:09)
ryans ♦♦
Thank you Ryans. Also, consider that the ETAG support can potentially save a lot of bandwidth :-)
(04 Sep '15, 09:22)
fra_t
Thank you, now the ETAG is always present in the response :-)
(05 Oct '15, 17:04)
fra_t
|
|
Nginx isn't dropping your etag. Here is the response directly from Apache on your server: ... and here is the response from Nginx: Both of them include the "ETag: W/c308e95ef263d84fa7676668e6922462" header. answered 02 Sep '15, 18:26 seanf Now I made some checks with different tools, and they give me different results: http://www.webconfs.com/http-header-check.php -> ETag included http://web-sniffer.net/ -> No ETag Firebug in my browser (IP from Italy) -> No ETag It seems like sometimes the ETags is included and sometimes is not. Maybe the IP/geolocation is the problem? Here is the Firebug responce I get:
(02 Sep '15, 22:10)
fra_t
|
If possible, could you please amend your question to include a URL that demonstrates the problem that you are reporting?
If you would rather not share that info here in the public forum, then feel free to open a support ticket instead.
Here is the URL: http://www.sosbiglietti.it/