Skip to content

Make sure Accept-Encoding is not forwarded upstream

Andrej Shadura requested to merge disable-compression into main

Some HTTP clients (e.g. Go’s) like to save traffic by requesting gzip compression of the HTTP responses (Accept-Encoding: gzip). When the server supports compression, it will set Content-Encoding: gzip and compress the response body.

However, Go’s HTTP client only transparently decoded gzip-compressed responses when it requests the compression on its own, but not when the user sets Accept-Encoding header:

DisableCompression, if true, prevents the Transport from requesting compression with an "Accept-Encoding: gzip" request header when the Request contains no existing Accept-Encoding value. If the Transport requests gzip on its own and gets a gzipped response, it's transparently decoded in the Response.Body. However, if the user explicitly requested gzip it is not automatically uncompressed.

As the result, the compressed body is returned as is, without the mediator knowing about it; it then spits it out to the requester without setting Content-Encoding header; however, if Content-Type header wasn’t set, Go’s HTTP server would automatically detect that the response body is compressed, and set Content-Type: application/x-gzip.

See T8346.

Edited by Andrej Shadura

Merge request reports