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