Do not compress responses with strong etags

[tanguilp]

etags between a compressed and an uncompressed response with same response content should be different per https://datatracker.ietf.org/doc/html/rfc7232#section-2.3.3

As far as I understand cowboy's compress handler is not compliant with this RFC. The problem is more complex but it seems no compressing responses with strong etags is sufficient to fix this issue.

See also:

• https://bz.apache.org/bugzilla/show_bug.cgi?id=39727
• https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

[essen]

Can you provide a scenario where it is possible for Cowboy to send a response to a request to the same URI where one ends up compressed and the other doesn't, when using the compress handler?

[tanguilp]

For example two instances of an application using Cowboy, one with compression enabled, and the other with compression disabled with CDN caching between them and the clients.

Maybe other scenarios I can't think of (Cowboy used as a proxy?).

Not a problem for me but just though it could be worth notifying.

[essen]

That's not an issue with Cowboy. Perhaps we can have a note about this in the cowboy_compress_h manual page instead.

[tanguilp]

Another (unlikely) scenario is a client requesting twice the same resource, once with Accept-Encoding: gzip and the second time without it. It might confuse the client's cache algorithm (I couldn't say how exactly though).

Bottom line is it seems to me it is not compliant with the aforementioned RFC, and any time there's a cache between the client and Cowboy it might lead to problems with cache updates or invalidation.

That said these a edge cases and I agree a note would indeed be sufficient.

[essen]

Right that one is a valid problem. I'm not sure a note is enough in that case. I will think about it.

[essen]

I will disable compression of responses that have an etag header and document this behavior.

[essen]

Done. Closing, thanks!

[tanguilp]

Thanks for the great work!