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