Re: Rechartering HTTPbis

On Thu, 2012-01-26 at 08:39 +0000, Poul-Henning Kamp wrote:

> 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 a problem with HTTP/1 that needs to be fixed in HTTP/2. not only
do you not know the server protocol version until you see the first
response you aren't actually guaranteed that the version applies to
anything except that one response.

Due to LB and scripting gateways we see the server response version
change in between response headers on the same connection all the time.

In http/2 We need to define a version level for the connection
properties that does not change once the connection is established, and
probably still allow individual responses to define what level of the
spec they were created at for their non-connection oriented headers to
be interpreted correctly.

SPDY has this problem tackled too. The spdy vs http/1 negotiation is
done as part of the SSL handshake using NPN. The negotiation doesn't add
any new round trips to the handshake and it allows either a clear path
for spdy or a fall back to http/1 before any application protocol bytes
are sent down the pipe. New versions of the protocol would be selected
in the same way.

And yes, I believe mandatory security is a desirable property to be able
to rely on 100% of the time. Some will disagree.

Received on Thursday, 26 January 2012 14:48:45 UTC