On Wed, Jan 01, 2020 at 07:19:48AM -0500, ohbarye wrote: Hi there,
> Hi, I'm using nginx as a reverse proxy and found a behavior that I wouldn't > expect. > So my question is: Is it expected behavior that nginx removes strong etags > on gzip compression? No, but: 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 ETag: "abc" or ETag: W/"abc" while your example sends something of the form ETag: abc and current nginx recognizes a weak etag when the first two characters are W/, and a strong etag when the first character is ". (Arguably: nginx could become more strict, and insist on W/" at the start and " at the end of a weak etag; and insist on " at the start and end of a strong etag; but I suspect that that is unnecessary.) The best fix in your case is probably to change your upstream to send valid headers. If that is not doable, then possibly you could patch your nginx to accept this invalid header; or possibly you could try some other config-based manipulation to make things work the way that you want. I suspect that either of those is likely to be more work in the long run than fixing the upstream. Cheers, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
