Re: Rechartering HTTPbis

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.

AYJ

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