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

Re: HPACK

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 18 Jun 2014 15:15:03 -0700
Message-ID: <CAP+FsNfEDurZFDfsrEsgd1LWZAhNTPEoVOQuBoqS0oCdsMaRBQ@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
Note that you don't actually have to copy anything, you just have to
account for it.
An entry in the dynamic table consisting of a bit and a reference to the
static entry would work, for instance.

Expressing it as 'copying' seemed to be the most clear way to get the point
across at the time it was written.

-=R


On Wed, Jun 18, 2014 at 2:30 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
>
> 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
> sense.
>
> 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
> implementors.
>
> 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 Wednesday, 18 June 2014 22:15:30 UTC

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