W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 6 Aug 2012 09:05:12 -0700
Message-ID: <CAP+FsNdBB9bZ0Kc-O5r0wpeWKrL+uxjaPvPSHO0fsrPbYSu31g@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Adrien W. de Croy" <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
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.

-=R
On Aug 6, 2012 12:14 AM, "Poul-Henning Kamp" <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>
> >>
> >>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 16:05:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 August 2012 16:05:54 GMT