#578 [was: Straw Poll: Restore Header Table and Static Table Indices]

This thread seems to be going off into defining an extension, which is entirely appropriate.

I'm not seeing broad acclaim for making any changes to the existing scheme in the spec itself; in particular, Jeff's proposal failed to get wide support. 

So, I think we can mark #578 as closed without action.

Regards,


> On 22 Oct 2014, at 1:24 am, Jason Greene <jason.greene@redhat.com> wrote:
> 
>> 
>> On Oct 21, 2014, at 4:32 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> 
>> --------
>> In message <20141021092505.GA30397@1wt.eu>, Willy Tarreau writes:
>> 
>>> I would guess they should appear in the order above, though that's not
>>> obvious to me. And I'm still sad at the idea of leaving many encoding
>>> values unused (eg: static header values above 16). Thus, we'll typically
>>> have 48 possible values out of 256 for the first byte that will never be
>>> emitted just for the indexed headers alone, that's a 20% waste, 
>> 
>> If you are that worried about wasted compression opportunities, you
>> should spend your time to get timestamps compressed to integers since
>> that will save more bytes than you can ever do by tweaking the current
>> HPACK in any way.
> 
> +Graham’s number
> 
> I am still surprised we aren’t doing this, as it would mean huge bandwidth and performance savings. I like the idea of an extension, which hopefully transitions to an official part of HTTP/3.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 22 October 2014 00:53:48 UTC