Fixes #166 [router] Return all response headers unmodified

[romanwozniak]

Context:

Issue: #166

Summary:

• Knative adds the Accept-Encoding: gzip header to each proxied request in all versions before 0.21.x (this behaviour was changed in v0.21: Avoid adding gzip-encoding to requests implicitly knative/serving#10691)
• Becasue if this, even if a client has sent a request without asking to compress the response, the requests to all internal components (such as routes, enricher, ensembler) will be made with Accept-Encoding: gzip, and if any of these components supports compression – the response will be gzipped
• Before sending the response back to the client, Knative looks if the request is compressed (response headers contain Content-Encoding: gzip) and decodes it accordingly
• But Turing router doesn't propagate headers from the ensembler, hence Content-Encoding: gzip is missing in the response that the router sends back to Knative's queue-proxy. And subsequently, Knative sends the response back to the client unmodified (i.e. compressed)

Solution:

In order to avoid such an unexpected behavior as returning a compressed response when the client doesn't request it, Turing router needs to let queue-proxy know if the response is compressed (i.e. propagate Content-Encoding header), so queue-proxy can handle it accordingly and decode the response before sending it to the client.
Currently, Turing router strips all of the response headers except Content-Type. This PR fixes this by propagating all of the responses back to the queue-proxy (and subsequently – the client).

[krithika369]

One (or 3) line PRs are the best. Thanks for the detailed explanation on the root cause. LGTM.

[ankurs]

@krithika369 @romanwozniak
I think I probably missed something, This PR is not going to prevent #166
clients will continue to receive compressed responses even when they do not request for it right ?

[romanwozniak]

@krithika369 @romanwozniak I think I probably missed something, This PR is not going to prevent #166 clients will continue to receive compressed responses even when they do not request for it right ?

Hey @ankurs, no, that's incorrect. Client will only receive compressed responses when they request for it by passing Accept-Encoding: gzip. The reason is that Turing routers are deployed as Knative services, and each request to Turing router is proxied through Knative's queue-proxy which controls the autoscaling behaviour and collects metrics. In the older versions of Knative, this queue-proxy adds Accept-Encoding: gzip header to each subsequent request (no matter if it was requested by the client) and decodes the received response after it (if the client doesn't support compression) or returns it unmodified (if client supports compression).

So if the client sends the request to turing-router with no Accep-Encoding: gzip, this router's queue-proxy will add such header automatically, but will decode any compressed responses from the downstream services, before sending it back to the client.

In addition to what is already described in this PR's description, you can also check knative/serving#10691 to understand the issue better.