Add SuffixETag() and DropETag() options to prevent ETag collisions on compressed responses

[willbicks]

I've been enjoying using compress/gzhttp as a drop in replacement for NYTimes's gzip middleware, so thanks for your effort here!

In a current project I'm looking to start using ETag headers for cache revalidation, and discovered that there's a few complicated implementation details that arise when combining ETags and content negotiation. Notably, RFC 7232 Section 2.3.3 explains with an example that an identical resource must have different ETags for compressed vs uncompressed versions.

Due to the convenient fact that this middleware is completely transparent to my handlers (where ETags are set), unfortunately it's not currently possible to meet the specification's requirement for different ETags served from my handlers. As such, I looked to expand the options available for configuring the compress middleware to include two new options:

• SuffixETag(string) , which adds a suffix to your existing ETag if it's compressed (e.g. W/"1234" -> W/"1234-gzip")
• DropETag(), which removes the ETag header for any requests that are compressed.

The most cautions approach (proposed here) is to make both these operations non-default and leave the current default functionality as is, despite the fact that it does not conform to the HTTP spec, but any input from maintainers on this decision would be much appreciated.

For context, Apache has struggled with this issue as well, and both of these came up as possible solutions: https://bz.apache.org/bugzilla/show_bug.cgi?id=39727

[klauspost]

Great stuff! Thanks for the contribution!