Keep content-encoding in a request attribute when using HTTP compression

[nicolas-grekas]

Removing this header means the consumer cannot assert if compression was used or not. And keeping it doesn't hurt in any way:

• if the request is done with an Accept-Encoding, the interceptor already and correctly does nothing.
• if the request is done without this request header, the client knows about it, so that it knows it should do nothing when Content-Encoding is found in the response.

Note that this is how curl-based clients work and this is fine and more useful. This is needed to resolve https://github.com/symfony/symfony/pull/35115#pullrequestreview-337185999

[kelunik]

If another decoding interceptor is in the chain or the response is forwarded to a client in a reverse proxy, this would result in double decoding. How about setting a request attribute if the body has been decoded?

[nicolas-grekas]

How about setting a request attribute if the body has been decoded?

works for me, updated

[nicolas-grekas]

I order to monitor the raw download count, I'm not going to use DecompressResponse, so that this is not needed anymore on my side.

[kelunik]

You could use two interceptors counting the size before and after and still use DecompressResponse.

[nicolas-grekas]

You could use two interceptors counting the size before and after and still use DecompressResponse.

Sure. Yet, implementing the logic is very simple - simpler than writing two interceptors I'd say, so that's how I did :)