Misalignment in content encoding between Http1.x and Http2

[bjornhusberg]

Pull request: #5372

The Http2 server-implementation handles content encoding differently compared to the Http1.x server-implementation, which leads to issues.

Http1.x:
The HttpContentCompressor determines the encoding based on the Accept-Encoding header right before writing the headers. If the request handler has already set a Content-Encoding header there will be no further encoding and if the Content-Encoding header is set to "identity" the header is removed by HttpChunkContentCompressor and the response is returned as-is.

Http2:
The encoding is determined already when setting up the stream in Http2ServerConnection and is then passed down to Http2ServerRequest and Http2ServerResponse where it is set using the Content-Encoding-header. The header content is later picked up by the CompressorHttp2ConnectionEncoder which compresses the response accordingly.

While the Http1.x-implementation works fine the Http2-implementation leads to two problems:

1. If the response is already encoded by the request handler and the Content-Encoding header has been set accordingly, the CompressorHttp2ConnectionEncoder picks up the encoding and encodes the response again, resulting in garbage returned to the client.

2. If the Content-Encoding is explicitly set to "identity", the response is not compressed by the CompressorHttp2ConnectionEncoder but the Content-Encoding holding "identity" leaks out to the client. This is unnecessary and leads to confusion for some clients.