nginx removes strong etags on gzip compression
ohbarye
nginx-forum at forum.nginx.org
Thu Jan 2 17:04:16 UTC 2020
To francis
Thank you for your answer.
> the thing that your upstream sends is not a thing that nginx recognizes as
a strong etag.
> The HTTP/1.1 RFC (https://tools.ietf.org/html/rfc7232#section-2.3) says
that the etag header must be of the form
Oh, I wasn't aware of the thing.
> The best fix in your case is probably to change your upstream to send
valid headers.
I tried making my upstream's header comply with the form that nginx
recognize as a strong etag like below, then nginx got working to downgrade
the strong etag to a weak one as I expected.
```diff
location /strong_etag {
- add_header Etag d41d8cd98f00b204e9800998ecf8427e;
+ add_header Etag '"d41d8cd98f00b204e9800998ecf8427e"';
default_type application/json;
return 200 '{"message": "Hello, this is from upstream!"}';
}
```
```shell
$ curl http://localhost:80/strong_etag -i -H "Accept-Encoding: gzip"
HTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Thu, 02 Jan 2020 16:49:06 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Etag: W/"d41d8cd98f00b204e9800998ecf8427e"
Content-Encoding: gzip
�V�M-.NLOU�RP�H����Q(��,V����\�҂⒢��\E�Z5[,%
```
The riddle was resolved.
---
To J.R.
Thanks for introducing
https://github.com/openresty/headers-more-nginx-module
I'll check it.
---
Again, many thanks!
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286645,286650#msg-286650
More information about the nginx
mailing list