Re: Compressing HTTP headers

On Mon, Jul 7, 2014 at 12:41 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CABkgnnX+vRXJgVBmD_Ai2mCc088HBcUeuS33pNYJic-KMMjJ1A@mail.gmail.com>,
> Martin Thomson w
> rites:
> >On 7 July 2014 05:33, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> >> As far as I can see, no space has been set aside for versioning HPACK
> >> nor for using entirely different algorithms for compression ?
> >
> >There are two options:
> >
> >* New setting (synchronization of use would have to rely on
> >acknowledgement; therefore, it would be delayed a little)
>
> Which goes directly against any reason anybody could have to
> try to improve the compression in the first place.
>
> >* New ALPN token
>
> Which makes it an all or nothing proposition, and precludes
> using different compressions for different header-sets,
> depending on circumstances etc.
>
> No, I really think we should reserve some bits (4-8) in the
> HEADERS frame for this purpose.
>

How do you know the peer supports the selected compression algorithm? If
there's a negotiation step, why don't we just use the ALPN token to resolve
negotiation without adding additional roundtrips?


>
> Considering how many bits people are willing to spend on
> the priority stuff, this cannot be a big deal...


> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>