- From: Jeroen de Borst <J.deBorst@F5.com>
- Date: Thu, 26 Jan 2012 15:01:34 +0000
- To: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>
- CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
That sounds a lot like WAP 1.x. This was justifiable given the memory and processing constraints of early mobile devices, but this became a dead-end: as soon as the devices were capable of doing regular HTTP the implementers switched to WAP 2.0 (completely HTTP 1.1 based)..... Interesting that a full circle is being considered. Zlib in SPDY turns out to be pretty efficient. Requests for inline links (which typically have a lot in common with the request for the parent page) compression causes the request to be ~10% in size of the original request. WAP 1.x encoding never seemed to go below ~50% (because certain headers like User-Agent couldn't be encoded as efficiently as the more structured headers). Jeroen -----Original Message----- From: Willy Tarreau [mailto:w@1wt.eu] Sent: Thursday, January 26, 2012 2:37 AM To: Julian Reschke Cc: Poul-Henning Kamp; Amos Jeffries; ietf-http-wg@w3.org Subject: Re: Header field name representation, was: Rechartering HTTPbis On Thu, Jan 26, 2012 at 11:13:28AM +0100, Julian Reschke wrote: > On 2012-01-26 10:35, Willy Tarreau wrote: > >... > >I find it pretty cumbersome to force everyone to support zlib, > >especially in environments where it provides no benefit (small > >requests/responses) and only adds CPU usage and latency. It's > >especially true on intermediary components which would have to > >decompress everything to be able to perform trivial actions such as > >decide what server to forward to. Using either pure binary header names or short forms would already be quite efficient. > >... > > What's a binary header name? Oh I'm realizing I wrote that ! I was meaning the use of enums instead of headers for the common ones. For instance, we could have bytes 0x80 to 0xFF directly mapped to most common headers and be able to represent 128 different headers with a single byte, and have the other chars for the other ones. We could even push the principle further and have the Connection header apply the same rules (eg: use high bytes to reference well-known headers or tokens). Regards, Willy
Received on Thursday, 26 January 2012 15:02:16 UTC