Re: Compressing HTTP headers

In message <CAA4WUYgROPSLubn5ergcVBi4-Yo7ZbhaafKtnvumUSAfzEykFw@mail.gmail.com>, =?UTF-8?B?V2lsbG
lhbSBDaGFuICjpmYjmmbrmmIwp?= writes:

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

Primarily because I can easily see different compression algoritms or different subsets
of one algoritm being used for different headersets.

Secondarily because it would allow us to make the HPACK reference an option.

Finally, given that we are going to mandate one compression algoritm as the
default, we know there will be no interop issue, everybody will
always be able to talk to each other.

All we need is SETTINGS_I_ALSO_SQUEEZE(list) and a flag in
HEADERS/PUSH_PROMISE which says how things are squeezed.

The first HEADERS from the client may not be able to take advantage
of alternate compressions but HPACK is good enough to make that a non-issue.

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

Received on Wednesday, 9 July 2014 06:21:56 UTC