Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

On Wed, Nov 20, 2013 at 08:23:38AM +0000, Poul-Henning Kamp wrote:
> In message <>, Willy Tarreau writes:
> >On Wed, Nov 20, 2013 at 04:08:49AM +0000, Adrien de Croy wrote:
> >> 
> >> my 2c is that http/2.0 (TLS or not) is enough of a departure from http, 
> >> that trying to put plaintext http/2.0 over port 80 will just be an 
> >> impossible nightmare.
> >
> >Changing the port will require to change the scheme as well otherwise
> >it will end up being even worse. For example, *right now* over the net
> >and even much more in corporate networks, you have many applications
> >running on non-80 ports. So when the browser will have to connect to
> >"", what version will it use ?
> Long time ago I argued that we should look into "no-RTT upgrade", ie
> a scheme where the first byte sent from client to server on HTTP/2
> would allow the server to decide which protocol it was.
> Together with an "Also:" or alt-svc header which announces which
> protocols are supported by the server, this could work seamlessly:
> 	if port == 100
> 		http/2
> 	elif we've seen Also: header announcing http/2
> 		http/2
> 	else
> 		http/1
> This idea may be worth revisiting.

Your "Also" header is in fact the Upgrade header :-)

Note that I'm regularly reading here that Upgrade always wastes a
round trip, which is wrong. First, when the browser knows that the
destination supports Upgrade, it can send the payload immediately
after the headers. Second, 101 is an interim response meaning that
the complete response is supposed to follow. So if you send something
like "OPTIONS * HTTP/1.1\r\nUpgrade: HTTP/2.0\r\n..." it will need
a round trip because we won't get any data with 101. But if you send
"GET / HTTP/1.1\r\nUpgrade: 2.0\r\n", the server must reply to this
request and provide the contents. The response can very well look
exactly like a server push in practice, in that from a 2.0 point
of view, the server sends first.


Received on Wednesday, 20 November 2013 09:04:31 UTC