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

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

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 27 Jun 2014 11:12:04 -0400
Message-ID: <CAOdDvNqmg+768+NSKdp4Qotab2e8beR-J-yH5bEn=X=M7nQf=w@mail.gmail.com>
To: Johnny Graettinger <jgraettinger@chromium.org>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
today's firefox nightly has h2-13 support btw. continuation support has
been around as long as its been in the spec, but we don't send them unless
there is just no room left in the headers.

I think pretty much nobody likes continuations, but we accept them as a
necessary long tail compatibility mechanism. It seems totally appropriate
for uninterested servers to 413 requests that use them - we certainly won't
generate a continuation unless we don't have another option. As with all
arbitrary limits (url length, etc..) allowing higher thresholds will buy
you interop at the tail - but you may not care about the tail.

-P



On Fri, Jun 27, 2014 at 10:56 AM, Johnny Graettinger <
jgraettinger@chromium.org> wrote:

> 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/
>>>
>>>
>>>
>>>
>>>
>>
>
Received on Friday, 27 June 2014 15:12:33 UTC

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