Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

fre 2012-03-02 klockan 02:11 -0800 skrev Mike Belshe:


> Alright, I overstated.  You can't get any HTTP/2.0 *advantages* until
> you take a round trip.  On the first load of a web page, that might be
> good enough, as the browser often only has one resource to fetch
> initially.

Yes, until you somehow know the server is HTTP/2.0 capable you would
prefer to keep sending HTTP/1.1 to it. Which is sending the initial
HTTP/1.1 request with an Upgrade token and immediately getting a 101
Switching Protocol intermediary response back, at which point you can
start hammer the server with following HTTP/2.0 requests.

The response to the initial request would be HTTP/2.0.

> No, on secondary connections, it is normal for the browser to have
> multiple resources ready to be fetched immediately.  Assuming HTTP/2.0
> wants to pick up multiplexing, this means that you want to be able to
> issue both requests right away.

What is secondary connections?

Secondary as in concurrent connections? (which I thought we should
avoid?)

Or connections taking place some time in future?

> However, if you're going to be compatible with HTTP/1.1 servers that
> could issue 505 responses as you suggest here, you're going to need
> the first header block to be 100% compatible with HTTP/1.1 header
> parsers, otherwise that poor HTTP/1.1 server will get confused and
> likely hang.  

Yes, the first request needs to be in a format such that the request
line, delimiting and a few other basic parameters is compatible with
HTTP/1.1 parsers.

> You could argue this is an edge case (downgrading), and that it is ok
> to hang the browser for 30 secs (or whatever it takes before the
> server gets tired of waiting for data that isn't coming from the
> browser).  This answer was never palatable enough to get pipelining
> turned on by default, though.

HTTP/1.1 pipelining have a number of issues.

> I didn't assume HTTP/2.0 would need to be parse-compatible with
> HTTP/1.1.  Maybe that's what you meant by "then it isn't HTTP".

Edge definition case.

HTTP is from HTTP/1.0 onwards designed with an immediate upgrade path
based on protocol version. This path requires the request line and most
likely header delimiting to be compatiblewith HTTP/1.x parsers.

HTTP/1.1 adds another upgrade path using the Upgrade token. This path
allows upgrading the connection to any protocol entirely

Both upgrade paths are hop-by-hop, not end-to-end.

Regards
Henrik

Received on Friday, 2 March 2012 12:05:21 UTC