gzip encoding breaks proxy

[pdf]

When sending a request through the proxy, and the target server supports gzip encoding, and the requesting client accepts gzip, then the proxy will produce no output.

When the Accept-Encoding header is not explicitly set on a request, the default http.Transport will add the header itself and transparently decode the resulting response body. However if the request explicitly sets the Accept-Encoding header, the response is not automatically decoded.

Because the proxy copies all headers from the client request to the proxied request, if the client is a browser it is very likely that the Accept-Encoding header will be explicitly set by the copy, with the result being that the proxy receives compressed data back from the server and barfs on it.

There are a couple of potential ways I can see to solve this:

• Omit the Accept-Encoding header when copying headers from client req to proxied req to allow transparent decompression. This approach may introduce some surprise if users expect to be able to specify some alternative encoding and have it honored.
• Handle decompression explicitly in the presence of Content-Encoding: gzip in the server response.

A similar issue exists on the proxied response, since the Content-Encoding header is copied to the outbound response but the response is not correctly encoded. I suspect that honoring the Content-Encoding header on the response side is likely to be rather more complicated, since the correct encoding on the response would have to be generated (gzip / compress / whatever).

[devgioele]

templ is Go module that includes a proxy with live-reloading. It decodes and re-encodes based on the header: https://github.com/a-h/templ/blob/main/cmd/templ/generatecmd/proxy/proxy.go#L92-L129

I tried moving the proxy of templ into air, but air interfaces in another way. Can anyone explain why there is a proxy_stream.go?