Re: Transfer-codings, mandatory content-coding support and intermediaries

On Sun, Apr 20, 2014 at 8:43 AM, Nicholas Hurley <hurley@todesschaf.org>wrote:

> +1 to everything Patrick has said.
>
> If, however, we end up doing some sort of (ill-advised) hop to hop
> transfer encoding, then it should absolutely be (1) optional, and (2)
> opt-IN (not opt-out, as Matthew's branch has it)
>
>
​+1 to what Nicholas wrote. I'd like to make it optional completely.

Best regards,
Tatsuhiro Tsujikawa




>
> On Sat, Apr 19, 2014 at 3:15 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:
>
>> nothing in this thread has really changed the basic design decisions
>> already in the current drafts
>>  * hop to hop transfer encodings have never been widely used successfully
>> - let's get rid of them
>>  * implicit end to end content encoding improves a known abuse of the
>> protocol.
>>
>> Sure, that makes http/2 gateways have to work a little harder with lame
>> http/1 clients. that's a reasonable price.
>>
>> i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip).
>> The alternative seems to be some form of per frame gzip changes at this
>> point with no implementation experience and a literal trail of tears in
>> recent non-content-aware compression schemes when mixed with TLS. Let's not
>> do that :)
>>
>> -P
>>
>>
>>
>> On Fri, Apr 18, 2014 at 2:52 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> We've had a wide-ranging discussion of the issues brought about by
>>> HTTP/2 dropping the concept of transfer-coding, in conjunction with the
>>> imposition of mandatory gzip content-coding support by clients.
>>>
>>> At this point, it looks like the folks who have asked for TE support in
>>> HTTP/2 are willing to wait on incorporating such a feature into HTTP/2.
>>> Since we don't seem to have much consensus on any of the proposals to date,
>>> the status quo seems like a good path forward -- although I think we should
>>> discuss this in more depth in NYC.
>>>
>>> However, discussion has also uncovered some problematic aspects of
>>> requiring clients to support GZIP content-encoding in HTTP/2.
>>>
>>> Specifically, we're chartered to enable intermediaries to translate from
>>> 1.1 to 2 and back with reasonable fidelity. As has been noted, that's hard
>>> to do if a HTTP/1 client doesn't support gzip content-encoding; if the
>>> HTTP/2 origin assumes gzip support, the intermediary has to decompress it,
>>> and -- importantly -- assign a new entity tag to the response.
>>>
>>> That's pretty clearly a major reduction in functionality, and
>>> effectively removes what we used to call semantic transparency from all
>>> HTTP1.x->HTTP2 proxies. As discussed, there are other side effects of this
>>> approach as well.
>>>
>>> I've created <https://github.com/http2/http2-spec/issues/460> to track
>>> this issue. I don't think it affects the current implementation draft, but
>>> we do need to discuss it before (and likely at) the NYC interim.
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Peace,
>   -Nick
>