W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Fri, 27 Jun 2014 21:26:24 +0900
Message-ID: <CAPyZ6=KyEfHqzod_MxRWgFrtTwUfKA8S6cRgWsGp93-85mMnZg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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/
>
>
>
>
>
Received on Friday, 27 June 2014 12:27:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC