Re: Moving forward with HTTP/2.0: proposed charter

On 8/6/12 7:05 PM, Roberto Peon wrote:
>
> That (http2 client  -> http2 proxy -> http1 server) could be 
> beneficial for mobile devices in terms of both latency and battery 
> life, so it isn't something we should dismiss.
>
indeed it is an area I would like we explicitly call out within the 
*charter* with the two following distinct bullets

* define a 2.0 mechanism for advising clients of the proxy to use

* http2 -> http1 interaction

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com


> -=R
>
> On Aug 6, 2012 12:14 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk 
> <mailto:phk@phk.freebsd.dk>> wrote:
>
>     In message <emc0d9c202-4de9-42a4-afcd-3e0714b94f4b@reboist>,
>     "Adrien de Croy" w
>     rites:
>
>     >>From: "Poul-Henning Kamp" <phk@phk.freebsd.dk
>     <mailto: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.
>