> Am 10.04.2019 um 16:34 schrieb Julian Reschke <julian.resc...@gmx.de>:
>
> On 10.04.2019 16:10, Stefan Eissing wrote:
>>
>>
>>> Am 10.04.2019 um 15:57 schrieb Julian Reschke <julian.resc...@gmx.de>:
>>>
>>> On 10.04.2019 14:53, Plüm, Rüdiger, Vodafone Group wrote:
>>>> ...
>>>> Not sure about this. I guess with TE each hop could be different in what
>>>> it accepts
>>>> and generates. This is different from CE. As far as I understand the
>>>> accept-encoding header
>>>> is only for CE not for TE.
>>>> ...
>>>
>>> Right (that would be "TE").
>>>
>>> That aside, maybe it's time to remind that HTTP/2 doesn't have transfer
>>> codings?
>>
>> You mean, it does not have "chunked".
>
> Not my reading...:
>
> "The only exception to this is the TE header field, which MAY be present
> in an HTTP/2 request; when it is, it MUST NOT contain any value other
> than "trailers"."
>
> <https://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.8.1.2.2.p.2>
Yeah, your reading is correct. There seems to be no wriggle room about that one.
This discourages efforts to extend transfer-encodings for HTTP/1.1. Using
HTTP/2 to the client in a reverse proxy is quite common. Those proxies could
pass transfer-encoded, gzipped resources only by uncompressing them. Bleh!
I think I will make an attempt at improving mod_deflate with a second filter
and see how complicated that gets. Alternate ideas always welcome. But
content-encoding it seems to be.
-Stefan
PS. The "keep-alive" warning indicator at redbot.org for testing an Apache
server is gone. Mark agreed to remove the "Connection: keep-alive" request
header, so Apache will not generate one in response. All's well.
