Re: Backwards compatibility

Hi William,

On Fri, Mar 30, 2012 at 06:29:55PM +0200, William Chan (?????????) wrote:
> On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson <watsonm@netflix.com> wrote:
> 
> > All,
> >
> > I'd like to make a plea/request/suggestion that wherever possible new
> > features be added incrementally to HTTP1.1, in a backwards compatible way,
> > in preference to a "new protocol" approach. A "new protocol" is required
> > only if it is not technically possible (or especially awkward) to add the
> > feature in a backwards compatible way.
> >
> > The object should be to enable incremental implementation and deployment
> > on a feature by feature basis, rather than all-or-nothing. HTTP1.1 has been
> > rather successful and there is an immense quantity of code and systems -
> > including intermediaries of various sorts - that work well with HTTP1.1. It
> > should be possible to add features to that code and those systems without
> > forklifting substantial amounts of it. It is better if intermediaries that
> > do not support the new features cause fallback to HTTP1.1 vs the
> > alternative of just blocking the new protocol. In particular, it should not
> > cost a round trip to fall back to HTTP1.1. It is often lamented that the
> > Internet is now the "port-80 network", but at least it is that.
> >
> 
> Don't forget port 443. And I agree, it should not cost a round trip to
> fallback to HTTP/1.1.

That's why I think we should make new measurements on Upgrade. Concerning
the 67% success that was reported two years ago for WebSocket, a very large
part of the failures was due to the server not getting the Upgrade header
and thus not upgrading the connection. For HTTP this simply means an implicit
fallback to 1.1 (which is in our proposal).

I also predict that with WebSocket being released now, vendors will be more
careful about better supporting, and particularly fix their bugs related to
the Upgrade+101 processing.

But at the moment I have no numbers.

> > Many of the features contemplated as solutions to the problems of HTTP1.1
> > can be implemented this way: avoiding head-of-line blocking of responses
> > just requires a request id that is dropped by intermediaries that don't
> > support it and echoed on responses. Request and response header compression
> > can be negotiated - again with a request flag that is just dropped by
> > unsupporting intermediaries. Pipelined requests could be canceled with a
> > new method. These things are responsible for most of the speed improvements
> > of SPDY, I believe.
> 
> It's unclear to me how this would work. Are you suggesting waiting a HTTP
> request/response pair to figure out if the id gets echoed, before trying to
> multiplex requests? Or would you rely on HTTP pipelining as a fallback if
> the ids don't get echoed? The former incurs a large latency cost. The
> latter depends very much on how deployable you view pipelining on the
> overall internet. I am skeptical it is sufficiently deployable and we on
> Chromium are gathering numbers to answer this question (
> http://crbug.com/110794). Also, pipelining is clearly inferior to
> multiplexing.

In our proposal, we have request headers to indicate which header fields
are to be kept for next requests, and a header to push several requests
into the pipeline if the Upgrade is accepted. This way we can have pipelining
from the first RTT when the Upgrade succeeds, and otherwise we have normal and
transparent 1.1 fallback if the Upgrade is not accepted.

Best regards,
Willy

Received on Friday, 30 March 2012 17:05:21 UTC