Re: HPACK

Roberto,

I agree that there is not need to copy the bytes.  But that is not the
expense that I'm concerned about.   You have to "copy" the reference to the
entry into the header table and account for it's size.  That means evicting
other entries and causing churn in the header table so useful entries have
to be resent again.

To avoid this table churn, jetty does not use the static entries for things
like :status:404, and instead send them as a non indexed literal with
indexed name and huffman value.  We only put 200 and 304 in the table as we
think they are the only ones for which repeat occurrences are likely, and
thus the table churn is not totally wasted effort.

cheers





On 19 June 2014 00:15, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>>
>
>


-- 
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.