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

Re: Optimizations vs Functionality vs Architecture

From: James M Snell <jasnell@gmail.com>
Date: Tue, 21 Aug 2012 20:03:43 -0700
Message-ID: <CABP7RbfGAb0dwmZdNtUVPfc9M7A9DuqZ8RxLvvbRxC84TZ=O9A@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
On Tue, Aug 21, 2012 at 7:43 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> [snip]
> * it exists and is already well defined.
> * it has existing implementations we can leverage.
> * it operates on next-hop independent of any connection complexity and
> most legacy software.
> * ANY hop can attempt to optimize/Upgrade.
> * it has a safe failure mode resulting in 1.1 being used.
> * worst-case cannot be worse than standard 1.1 performance (since failure
> ist to use 1.1).
> The downside is all in the implementation code specifics. ie it is *our*
> problem to find easy implentation methods, not impacting the users.
Ok.. so how exactly would this work... suppose all I want to do is a simple
HTTP GET. Am I going to send a 1.1 GET request with an Upgrade header and
wait for the response to come back as HTTP/2.0 or do I send an HTTP 1.1
OPTIONS request with upgrade, check to see if 2.0 is supported, then send a
HTTP 2.0 GET request second? In the former case, assuming we are indeed
using SPDY, we won't have an established SPDY Stream yet within which to
send the response so I'm not quite sure how that's suppose to work. In the
latter case, we're wasting one RTT to upgrade the request (which,
thankfully, should only need to happen once per connection...).

- James

> Amos
Received on Wednesday, 22 August 2012 03:04:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC