Re: CONTINUATION was: #540: "jumbo" frames

Chromium has accepted CONTINUATION frames since h2-12, and should be
sending CONTINUATION as of yesterday (when h2-13 changes landed). Headers
large enough to require them have been hit in interop testing, and I know
this because I get the bug reports and had initially omitted hooking them
up properly :)

I'm personally not that interested in talking about it, because I have
trouble keeping up with the list traffic as it is, and because I don't see
them as particularly burdensome to implement.


On Fri, Jun 27, 2014 at 8:26 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
wrote:

>
>
>
> On Fri, Jun 27, 2014 at 7:53 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> Simone,
>>
>> On 27 Jun 2014, at 7:36 pm, Simone Bordet <simone.bordet@gmail.com>
>> wrote:
>>
>> > FWIW, the Jetty implementation for web browsing is complete, and we
>> > would have already put it out in the wild if browsers did not have
>> > fatal bugs (crashes) that are being addressed as we speak.
>> > It does not support CONTINUATIONS.
>> >
>> > There is large majority of the people intervening in this thread that
>> > is against CONTINUATIONS are they are defined now, and I am one of
>> > them.
>> >
>> > I read this as rough consensus and working code to *not* support
>> > CONTINUATIONS are they are defined now.
>> >
>> > I am wondering what is the exact reason the editors do not want to go
>> > the direction the expert group suggests ?
>> > What it is needed to have this happen ?
>>
>> Hold on there.
>>
>> It’s great that Jetty is implementing now — welcome! — but characterising
>> your objections plus that of other folks who haven’t implemented as an
>> expert group vs. the editors’ whims is hugely disrespectful of the nearly
>> 20 other implementations that have spent nearly two years working on this,
>> not to mention the effort of the editors.
>>
>> At the risk of repeating myself — most of the implementers are currently
>> being quiet, both because they’re busy getting -13 up to scratch, and
>> frankly I suspect that they don’t want to re-hash the discussion yet again,
>> after doing it for two years (and sometimes more). While this is new to
>> you, it’s well-worn territory for most of the WG, and this is not a random
>> decision by the editors.
>>
>> As part of the next implementation draft and WGLC, we will assess how
>> well CONTINUATION is implemented, and any problems that it brings. If it's
>> found lacking, we’ll discuss alternatives. At this moment, though, we’re
>> not in a place where we’re going to abandon a feature or re-engineer the
>> protocol without cause; so far CONTINUATION has *not* come up as a problem
>> in the substantial body of running code that we have.
>>
>> Having said all of that, I’d very much like to hear from other
>> implementers what the current status of their CONTINUATION support is, and
>> what testing plans they have for it.
>>
>>
> ​nghttp2 implements CONTINUATION frame.​  Since curl and mruby-http2 use
> nghttp2 as HTTP/2 backend, they also support the feature as well.
> nghttp command line client included in nghttp2 has convenient option
> namely --continuation to send large headers with CONTINUATION to server for
> testing purpose.
>
> ​Recently I wrote a patch to upgrade wireshark dissector to h2-13, and
> found that it also supports CONTINUATION.  It successfully dissects
> HEADERS+CONTINUATION sent from nghttp.
>
> ​Best regards,
> Tatsuhiro Tsujikawa​
>
>
>
>
>> Thanks,
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>