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

Re: Large Frame Proposal

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 7 Jul 2014 15:43:35 -0700
Message-ID: <CAP+FsNcxaLmfDcJc_ANzqpN-ja-2mzaOQKYvJ2rmcs_OX0kS7g@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 7, 2014 at 3:23 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 8 July 2014 04:23, Johnny Graettinger <jgraettinger@chromium.org>
> wrote:
>> Hi Greg et al,
>> Thanks for the proposal! Some non-anticipated feedback:
>> This is orthogonal to CONTINUATION (and could also be addressed by
>> pre-pending the encoding length within the HPACK encoding, as has been
>> suggested). The problem with doing so is that it precludes the possibility
>> of streaming HPACK.
> Streaming HPACK is already not possible as it creates DoS vectors.
> Either we fix that problem - ie make header blocks able to be fragmented
> and interleaved,  or we have to face up to the fact that we already have
> jumbo header frames.
Not all use-cases have potentially malicious users, and jumbo frames do not
solve the blocking problem.
Making frames after the first one non-state-modifying or
non-state-referencing, however, would solve that problem.

> It's not a requirement that an endpoint close the connection after
>> deciding that headers on a particular stream are too large. It does require
>> that the endpoint be willing to incrementally process header block
>> fragments as they arrive, to avoid unbounded buffering. With that, it's
>> fully possible for an endpoint to tightly bound it's memory commitment in
>> the face of large headers on a stream, without tearing down the connection.
> Indeed - but a lot of work for nothing. Best just to tell the peer not to
> send them in the first place.

And what if you're forwarding to another multiplexing proxy, and only then
to a server?
Which limit applies to which request?
It gets complicated and unuseful, and one needs to be able to reject
larger-than-wanted headers anyway.


>> Yes, this is a concern, but is easily solved (and is why Chromium is
>> emitting smaller continuation frames to ensure good interop coverage within
>> h2-13).
> Which is precisely the reason I have moved from the
> I-can-live-with-CONTINUATIONS-because-I-can-ignore them camp, back to the
> I-can-not-live-with-CONTINUATIONS camp.      Several proposals have been
> made to make them ignorable for small headers, but as they have not been
> accepted then it looks like we all must support continuations and
> implementations that do not will be hunted down and excluded from
> interoperability, even if they never ever need large headers.
> Mark - can you open an issue for this one-   CONTINUATIONS looks like it
> is only needed for large headers, but it is actually a non optional part of
> the specification.
> cheers
> --
> 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.
Received on Monday, 7 July 2014 22:44:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC