Re: Striving for Compromise (Consensus?)

I'm a bit confused (definitely not the first time). Will somebody please help me understand why we still need CONTINUATION frames if we remove the hpack reference set?

In other words, why can't a request look like:
1*HEADERS [1*DATA]

and a response:
1*HEADERS [1*DATA] [1*HEADERS]

with the constraint that all frames may be interleaved, but HEADERS frames must be processed in order.

-confused in Vienna


> On Jul 11, 2014, at 10:30, "w@1wt.eu" <w@1wt.eu> wrote:
>
>> On Fri, Jul 11, 2014 at 06:03:48PM +1000, Mark Nottingham wrote:
>> Hi Jeff,
>>
>> Thanks. Based on the discussion today, I'm open to this.
>>
>> From where I sit, the only one that seems controversial is #4 - and we've
>> already seen a proposed modification from Greg.
>>
>> Personally, I wonder if we can just ditch #4 and still have reasonable
>> properties; an implementation that receives too many CONTINUATIONS can reset
>> the stream and continue to process other streams, correct?
>
> But that would rule out one key point of the proposal :
>
>>> For implementors that know that they will never accept more than 64kb
>>> of headers, they don't have to implement CONTINUATION frames.
>
> so that's not really an option here.
>
> Willy
>
>
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 11 July 2014 08:54:24 UTC