Re: Working Group Last Call: draft-ietf-httpbis-http2-14 and draft-ietf-httpbis-header-compression-09

Mark,

Now we are at LC, I think the FAQ http://http2.github.io/faq  needs a fair
bit of updating, at least with regards to continuations.

Specifically I would like to see the FAQ
Why the rules around Continuation on HEADERS frames?
to be expanded into the following FAQs.


*Why are there CONTINUATION frames?Why can't CONTINUATION frames be
interleaved?*
*Why can CONTINUATION frames be sent after a frame with the END_STREAM flag
set?*


I'm not the best placed person to provide text to answer these FAQ's but I
will have a stab at it anyway:




*Why are there CONTINUATION frames?*
CONTINUATION frames were added to HTTP/2 to allow large headers to be sent
when then draft had a 2^16 maximum frame size.   Now that the maximum frame
is 2^24, while not infinite, effectively all reasonable large headers can
be sent in a single frame.     However, the HPACK encoded size of the
headers must be known in order to create the frame header , which prevents
a sender from streaming headers as they are encoded.

Thus CONTINUATIONs have been left in HTTP/2 to support the streaming of
arbitrary large headers.

Note that streaming headers in CONTINUATION frames can have a significant
negative impact on Quality of Service, as a partially sent header will
prevent all other streams from progressing as CONTINUATION frames cannot be
interleaved.


*Why can't CONTINUATION frames be interleaved?*

Originally CONTINUATION frames were not permitted to be interleaved with
other frames due to the stateful ReferenceSet used by HPACK encoding
(drafts<=8).   Now, without the ReferenceSet there is no technical reason
that prevents interleaving.

A DoS concern was expressed that to allowing interleaving would open up an
attack vector where a malevolent sender could open many streams, each with
a partially complete header.  This could cause intermediaries and servers
to hold those many partial headers in memory.

This concern was argued against as the protocol is already vulnerable to a
similar attack where a malevolent sender can open many streams, each with
partially completed data and many implementations will hold headers while
processing data and those that don't could stream partial headers if
interleaving was permitted.

However consensus was not able to reached on these point so the restriction
to prevent interleaving of CONTINUATIONS was not removed from the
specification.

Note that the inability to interleave CONTINUATIONs can have a significant
impact on quality of service, as a stream with large headers will prevent
other streams from progressing and headers are excluded from flow control
calculations.


*Why can CONTINUATION frames be sent after a frame with the END_STREAM flag
set?*

No idea really?!?!  Something about not allowing a response stream not
being able to end with a push promise????  But then it can't just end with
lots of things (eg HEADERS with END_FRAME but no END_HEADERS,  or a
content-length but insufficient data frames) and they don't get baked into
the framing????

Somebody else better write this one.








On 1 August 2014 10:54, Mark Nottingham <mnot@mnot.net> wrote:

> Everyone,
>
> The editors have published new drafts of HTTP/2 and HPACK:
>   http://tools.ietf.org/html/draft-ietf-httpbis-http2-14
>   http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09
>
> ... and our issues list is currently empty. As such, this message begins
> Working Group Last Call on these documents.
>
> Please review the documents carefully, and comment on this list. One of
> the goals of WGLC is to assess consensus on the document, so expressing
> your support (or lack thereof) as well as implementation status / plans is
> important.
>
> If you find editorial issues, you can raise them directly on github <
> https://github.com/http2/http2-spec/issues> (ideally with a pull
> request), or directly to the editors.
>
> WGLC will end on 1 September.
>
> At the NYC interim, we discussed a plan for doing interop before closing
> WGLC, based upon draft-13/-08. However, there have been a number of changes
> in the wire format for draft-14/-09, and it would be good to see interop
> for them. After discussing this with most of the implementers that
> indicated interest in NYC, we're going to call -14/-09 an interop draft as
> well.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.