W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Getting to Consensus: CONTINUATION-related issues

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 18 Jul 2014 13:15:40 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <5B47ECBB-BBE3-49F7-99D5-CB02F8284ED4@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>

On 18 Jul 2014, at 12:53 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 18/07/2014 12:44 p.m., Mark Nottingham wrote:
>> We've had a rollicking discussion about the design tradeoffs in CONTINUATION, especially regarding HOL blocking and DoS considerations.
>> 
>> I see very little new information entering that discussion, and I think everyone has come to understand the tradeoffs. For a refresher, please see the wiki:
>>  https://github.com/http2/http2-spec/wiki/ContinuationProposals
>> 
>> I proposed two options the other day:
>> 
>> a) Remove CONTINUATION from the specification and add a new setting that dictates the maximum HEADERS/PUSH_PROMISE frame size (as distinct from max_frame_size) a peer is willing to receive. I.e., the setting refers to the compressed header size.
>> 
>> b) Keep CONTINUATION in the specification, and add a new setting that advises the maximum header set size (i.e,. uncompressed) a peer is willing to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt).
>> 
>> Although there have been some tentative proposals for additional options since, I haven't heard a clamour for support for them, so I think these are realistically the ways we can go.
>> 
>> As stated before, there will no doubt be tweaking and adjustments made to these, but I think we're in a place where we can choose a general direction.
>> 
>> I'd like to hear:
>> 
>> 1) Your preferred outcome (if any)
> 
> (A).
> 
>> 2) Whether you can live with the other option, and if not, why
> 
> "CONTINUATION without a length limit" adds a great complexity to the
> intermediary code and opens us to unacceptible levels of resource
> commitments for the rare[1] chance of being useful. In 1.1 this is only
> just coped with, in h2 with multiplexing it grows unacceptible.
> 
> "CONTINUATION with a length limit" is simpler both for spec and
> implementation when written in the form of a Large Frame
> unlimited-length value for use only by 1:1 "TCP tunnel" type proxying
> where h2 as a whole ceases relevance.
> 
> [1] Specifically the unlimited length need is rare. As opposed to
> knowable but large lengths, which are far more common.

Hi Amos -- please be explicit -- is this the reasoning for your preference, or a statement of why you can't live with it?

(I ask because "can't live with it" is a big statement either way, and we need to make sure it's unambiguous when it's said).

Thanks,





--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 18 July 2014 03:16:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC