W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Rechartering HTTPbis

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 26 Jan 2012 23:14:48 +1300
Message-ID: <4F212798.4080205@treenet.co.nz>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
CC: Willy Tarreau <w@1wt.eu>, ietf-http-wg@w3.org
On 26/01/2012 10:48 p.m., Poul-Henning Kamp wrote:
> In message<20120126093557.GA8887@1wt.eu>, Willy Tarreau writes:
>> On Thu, Jan 26, 2012 at 08:39:00AM +0000, Poul-Henning Kamp wrote:
>> I find it pretty cumbersome to force everyone to support zlib, especially
>> in environments where it provides no benefit (small requests/responses)
> Actually if you look at it, you can simulate ZLIB in null-mode trivially,
> so that is not really a valid concern.
> It's an idea, I'm not sure if it is a really good idea, but the current
> handling of compression is worse.
> Compressing cookies would save a lot of bytes, but those are content-metadata
> so maybe there are less draconian means.
> One benefit of compressing the entire connection is that it offers
> "privacy-light", the simple malware which just snoops packets and
> searches for "password:" etc, would be out of the picture.

no gain. compression is equally mandatory and open to snoops as for 
other software.

>> Making trailers mandatory will cause a lot of pain to static servers
>> relying on sendfile() and equivalent mechanisms.
> Nobody forces them to send any trailers...
> I'm perfectly happy with announcing the intention to send trailers
> in the headers.  (Sort of like postscripts "atend")

Yet if you want to rely on it for broken connections it must be sent or 
that reliance fails.

>> There's no one-size-fits-all. Having small chunks (eg: 256 bytes) will
>> cause a huge overhead for very small exchanges (eg: auto-completion),
>> while at the same time significantly reduce on-wire efficiency and CPU
>> efficiency. Chunking works remarkably well for all sizes nowadays, let's
>> not reinvent something which works well.
> If you made the chunked header look like:
> 	\nXXXXXX\n
> Instead of the current
> 	\r\nX*\r\n
> Then the difference in efficiency is utterly marginal for transmitters
> but very big for receivers.

16-bit binary numeric length should be long enough for any one chunk 
overhead. One can have multiple chunks inside a Jumbo packet as easily 
as fragmented over multiple packets.

Received on Thursday, 26 January 2012 10:15:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC