- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 29 Nov 2017 08:17:49 +0100
- To: Mike Bishop <mbishop@evequefou.be>
- Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
On Tue, Nov 28, 2017 at 06:32:15PM +0000, Mike Bishop wrote:
> I agree that HPACK is largely decouplable from HTTP/2, or HTTP. The core of
> the protocol is a general-purpose compression algorithm for streaming
> key-value dictionaries, rather than straight text. The pieces that bind it
> to H2 are incidental, and perhaps we could have structured it differently.
I think there are just a few points raised following HPACK that deserve
being mentionned in httpter for future designs, and it would be good to
have a "header compression" section to centralize them. We at least had
to accept that :
- cookies can be sent as individual header fields and have to be folded
using "; " unlike other headers using ", ".
- leading and trailing LWS in values are dropped (since compression
removes them before looking up values in dictionnaries)
- status reason is dropped
- header field names case is changed along the path
- header field names cannot contain a colon
- quite a number of header field values belong to a well known set
I know that these ones result from protocol properties that we already
know, but by definition, compression tries to make efficient use of known
properties and tend to exploit them all at once. As a result, non-compliant
implementations tend to be much more stressed by compression than by usual
traffic. And in addition it should encourage more compression-friendly
improvements over time.
Willy
Received on Wednesday, 29 November 2017 07:18:21 UTC