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

Re: Interleaving #481 (was Re: Limiting header block size)

From: Greg Wilkins <gregw@intalio.com>
Date: Tue, 3 Jun 2014 23:13:15 +0200
Message-ID: <CAH_y2NH4mTMzFTBDDkAG8rPjhtVhh-vHu3HYFx=vy8HQ7hw3Nw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Simone Bordet <simone.bordet@gmail.com>, Michael Sweet <msweet@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 3 June 2014 22:49, Martin Thomson <martin.thomson@gmail.com> wrote:

> > But I would also point out that the proposal I made above does support
> > arbitrary sized headers.
>
> Not quite.  Arbitrary sized blocks, but not individual fields.  Long
> URLs and cookies are a part of the landscape unfortunately.


Well it should be pretty simple to either modify hpack to support field
aggregation or come up with a field naming convention to support
aggregation of fields from different sets.

My proposal would then still allow arbitrarily large meta data sets and
fields - it would just keep them out of the transport meta data channel
which intermediaries and servers have to handle specially.

Yes there are current examples of some fields approaching 64KB (thanks
Mike), but their existence is not an argument to make the transport meta
channel unlimited.  Those near 64KB use-cases are examples of exactly the
kind of usage creep that will consume more and more resources from the
intermediaries and servers unless we put a stop to it and offer them a more
suitable channel for this application meta data.

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 Tuesday, 3 June 2014 21:13:43 UTC

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