nginx removes strong etags on gzip compression

[Francis Daly]

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        francis at daoine.org