0

It's said that Transport will handle the Content-Encoding automatically (like auto decompressing when reading from resp.Body).

It's also said that, Content-Encoding is an end-to-end HTTP header, not a hop-by-hop one.

Therefore, if a proxy copied Content-Encoding back to client's response header, and this proxy also io.Copy the upstream response body (which may decompressing automatically since io.Copy will read from resp.Body), won't it be inconsistent to client? (Content-Encoding copied from upstream response, but body has been decompressed)

dastan
  • 1,006
  • 1
  • 16
  • 36

1 Answers1

0

In general, the Content-Encoding response header should not be altered by a proxy.

Different encodings of the same URI are deemed to be different representations and have different ETags. So, changing Content-Encoding would not play well with caching.

But if it's your own proxy and client in your own ecosystem, you could do it, since you know what's going on, so if your proxy is decompressing data back to the client you'd need to strip the Content-Encoding header.

Adrien
  • 1,061
  • 8
  • 11
  • So in `go`, when I use `io.Copy(rw, resp.Body)`, should I copy the `Content-Encoding` header or not? – dastan Sep 09 '16 at 08:52