Re: Re[2]: Moving forward with HTTP/2.0: proposed charter

In message <emc0d9c202-4de9-42a4-afcd-3e0714b94f4b@reboist>, "Adrien de Croy" w
rites:

>>From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
>>
>>Where does 2.0<-->1.1 conversion _realistically_ come into play ?

>You mean where are we most likely to see 2.0 down-graded to 1.1?
>
>I think this will be extremely common for a very long time.
>
>2.0 client talks to 2.0 local proxy talking to 1.1 internet.

That's not a terribly interesting use-case is it ?

The RTT to a local proxy is not prohibitive, so running HTTP/2.0
on that path will gain you very little performance, and insisting
on running both 2.0 and 1.1 would cost very little, since the
link is very likely a LAN.

So yeah, you have a shiny new protocol, but it doesn't do anything
for you...

(The GET https://... thing can be done as extension to 1.1 also,
so that is not a deciding factor)

The RTT performance gain of 2.0 only happens once 2.0 deploys on
the far (ie: server) side of things.

So I think the interesting use-case is the opposite of what
you suggest: 1.1 to proxy, 2.0 to server.

About the only other place I see a credible case for conversion
is a 1.1+2.0 load-balancer and a 1.1- or 2.0- only server.

The 2.0->1.1 case I can conceiveably see, in a somewhat strange set
of circumstances, but the 1.1->2.0 case seems entirely speculative
for the next many years.

Given how much simpler it will be for everybody, I still see a
"same version, end to end" model as very attractive.

Of course 1.1 and 2.0 must still interoperate, in particular we
need to be able to upgrade (and later downgrade ?) on port 80.

But I really have a hard time seeing the a business-case for
specifying conversion of individual requests and responses between
1.1 and 2.0.

-- 
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 Monday, 6 August 2012 07:12:01 UTC