Re: Rechartering HTTPbis

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.

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.

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.

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

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


-- 
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:20:55 UTC