Re: Rechartering HTTPbis

On Thu, Jan 26, 2012 at 08:39:00AM +0000, Poul-Henning Kamp wrote:
> In message <3242f7d9fe2f4046819ab4fcbafab251@treenet.co.nz>, Amos Jeffries writ
> es:
> 
> >So how would compression type be embeded in the request-line in a way 
> >not to break HTTP/1.1 servers receiving it?
> 
> First of all, I would not allow different compression types.  It's ZLIB
> and it's mandatory.

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.

> Second, we cannot know if the other end is HTTP/1.1 or HTTP/2.0 until
> we see its reply, so the first request would always be in HTTP/1.1 format.

That's the exact principle of the current Upgrade mechanism.

> One way to indicate the shift to compressed HTTP/2.0 would be that
> the first character of the second request is 'Z', and the entire
> connection is compressed from then on.

Better rely on Upgrade. It's well documented and is already used by Websocket.
A number of other alternatives had to be ditched out because they were not
reliable enough through intermediaries.

> @ Amos Jeffries:
> 
> (about trailer updates to information)
> 
> >Provided that the trailer details are limited to transport meta data 
> >like your example case.
> 
> Yes, absolutely.  The content metadata should be transparent from one
> end to the other through all intermediaries.
> 
> @Adrien de Croy <adrien@qbik.com>
> 
> 
> >Actually this raises the issue of aborting transfers.
> >
> >Currently to abort a chunked transfer, you must close the connection.  
> >(and this triggers all sorts of nasty buggy behaviour in browsers - most 
> >of which don't complain).
> >
> >It would be nice if the chunk header could signal an abort.
> 
> That is one of the primary reasons why I want trailers mandatory:  To
> be able to kill a transfer that went awry half way through without
> abandonning the connection.

Making trailers mandatory will cause a lot of pain to static servers
relying on sendfile() and equivalent mechanisms. 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.

> @Willy Tarreau:
> 
> >It's already possible, we can add attributes on chunk sizes. We could
> >already have something like this to abort the transfer :
> >
> >     0;reason=abort\r\n
> 
> First: YUCK!
> 
> Second: That ditches the entire object.  In many cases a 206 would be
> perfectly fine.
> 
> Third: That reminds me of another thing:  Make the chunk header a fixed
> size to improve efficiency.

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.

Willy

Received on Thursday, 26 January 2012 09:36:50 UTC