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


From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 18 Jun 2014 23:30:06 +0200
Message-ID: <CAH_y2NFw5AY70qRG17AzV8kTC6P9-79S27t6iLq94FeT_ZnN-Q@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
On 18 June 2014 20:24, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

> The copying is there because otherwise, the reference set would include
> things in the static table.  There was a push for operation to be totally
> stateless with a context size of zero, which it’s not if you have to track
> the reference set between requests even without a header table.

Ah, that's the first I've heard that argument.... and at least it makes

But surely the copy is a pretty expensive cost on normal stateful operation
in order  to support a possible desire for stateless operation.   It would
have been fair better to just say that if the max table size is 0, then you
can't add entries to the reference set.

(Alternately, you could say that referencing something in the static table
> *doesn’t* add it to the reference set, but then you’re forking the
> semantics of the two tables even further, and the most common headers have
> to be re-sent every time.)

Actually I think it would have been good to have the semantic to reference
static entries without adding them to the reference set.   Fields like
:status:404 are hopefully not going to be repeated on the next response.

> I’m certainly not going to argue that what we have is perfect, but I will
> argue that we previously had some of what’s being proposed, and we moved
> away from it based on data and the consensus of implementers.
Sure - and it's good enough to go forward as we are to get more data and


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 Wednesday, 18 June 2014 21:30:37 UTC

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