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 _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
