Re: YAC Proposal

If we are required to deal with CONTINUATION instead of jumbo frames I 
would much rather deal with this than the status quo definition.

Some nits on this proposal:

* IMHO, the END_STREAM flag should be allowed/moved to the last 
CONTINUATION. Both endpoints have explicitly negotiated this feature, so 
moving the END_STREAM flag is already agreed between them. There is no 
reason for it to be set on the HEADERS at all and it just adds confusion 
over where the stream actually ends from a naive framing viewpoint.

* Would it make sense having the SETTINGS_ENABLE_CONTINUATION value 
indicate the count of CONTINUATION frames that will be accepted? That 
would allow a rough 16K resolution on acceptible compressed size limit 
to be negotiated.


PS. reminders to everyone objecting so far:

1) the primary use case presented for large headers is Kerberos tickets 
in Negotiate connection-based authentication. That already requires 
dedicated end-to-end "connection pinning" implementation support in 
HTTP/2 (HTTP/1 gets away with closing connections after each request - 
which is not an option now). In light of that, making CONTINUATION 
require *negotiated* end-to-end implementation support is actually an 
overall gain as we can identify more cases of failure in advance - along 
with a clear reason for failure.

2) the secondary use case; large sets of Set-Cookie to clear cookies 
seems to be better served with an extension to create a end-to-end 
"clear cookies" frame type or an application level object inside the 
DATA payload.

Do we actually have any other real-world use cases for large headers 
that need to be considered?

Amos


On 2014-07-03 12:21, Roberto Peon wrote:
> 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.
>>> 
>>> 
>>

Received on Thursday, 3 July 2014 01:42:59 UTC