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

+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)


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