Re: Rechartering HTTPbis

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.

>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")

>Really, I think that
>current chunking already offers provisions for reporting issues, and
>that trying to improve the minority of unrecoverable error situations
>will cost a lot for many components in the normal case.

No, chunking offers no way to report anything, all you can do is
close the connection.

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

-- 
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 Thursday, 26 January 2012 09:48:40 UTC