Re: YAC Proposal

One cannot remove continuation without addressing backwards compatibility
with HTTP/1.1 deployments sending large headers.

The status quo, or a variation which improves the state machine around
continuation (e.g. by moving the flags to the last frame of the headers
block) makes the most sense to me
-=R


On Wed, Jul 2, 2014 at 4:22 PM, Nicholas Hurley <hurley@todesschaf.org>
wrote:

> This sounds like a non-starter, to me. As mentioned in the other thread, I
> prefer either the status quo, or failing that a stateless CONTINUATION.
> This seems worse to me than either of those options. With a stateless
> CONTINUATION, in the rare occasions when I'll encounter a compressed header
> block > 16k, I can roll back just one step in my HPACK compression, and
> then continue on sending an uncompressed form of the headers. With
> CONTINUATION as an extension, when the other side doesn't advertise
> support, I would either have to either roll back the entire HPACK state
> that I changed when trying to compress the headers and generate a
> RST_STREAM (likely synthesizing an 413 or some other error in the process
> for my own side), or I'd have to send a GOAWAY, and dial back. Neither of
> those options is in any way more appealing than stateless CONTINUATION
> (which I'm still not entirely sold on to begin with!)
>
> --
> Peace,
>   -Nick
>
>
> On Wed, Jul 2, 2014 at 12:51 PM, <K.Morgan@iaea.org> wrote:
>
>> I'd like to propose yet another option to Mark's list of options for
>> dealing with the "CONTINUATION issue".
>>
>> Make it an extension.
>>
>> In NYC several people mentioned that if we add extensibility, we should
>> have an extension(s) right from the start that are used.  CONTINUATION IMO
>> is a good option for an extension.
>>
>> Here is the CONTINUATION extension draft:
>> http://www.ietf.org/id/draft-johndoe-http2-large-header-blocks-00.txt
>>
>> Here is the pull request to remove CONTINUATION from the core h2 draft:
>> https://github.com/http2/http2-spec/pull/547
>>
>> -keith
>>
>> 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.
>>
>>
>