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

Re: Backwards compatibility

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 31 Mar 2012 09:13:33 +0200
To: Roberto Peon <grmocg@gmail.com>
Cc: Mark Watson <watsonm@netflix.com>, Mike Belshe <mike@belshe.com>, "William Chan (?????????)" <willchan@chromium.org>, "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Message-ID: <20120331071333.GL14039@1wt.eu>
Hi Roberto,

On Sat, Mar 31, 2012 at 03:22:20AM +0200, Roberto Peon wrote:
> HTTP is widely deployed, but most certainly not well understood :/
> In any case... a number of clients and servers have implemented SPDY, and
> haven't had any problems with deployment, nor big problems with
> implementation.
> What I understand that you're proposing is to build off HTTP/1.1's current
> framing, but bolting on multiplexing (via response IDs), interleaving, and
> prioritization. Note that you'll have to also do interleaving on the
> request path to avoid HOL blocking there, e.g. when someone decides to POST
> a video. I don't believe that this is trivial to make backwards
> compatible... in fact, I think that the assumption that "building off of
> current HTTP framing semantics is easier" is just plain not true. Hell, one
> of the reasons I started SPDY with Mike was my more-than-slightly-strong
> distaste for HTTP's framing after having to write a production-quality
> framer for an intermediary that sees a lot of traffic (from billions of
> people). It is the details that get you-- those niggly little pesky
> annoying things.
> SPDY doesn't have that problem with framing. The frames are well defined
> and you don't have to dip into the application layer at any time to figure
> out how to frame the dang frames. I hope that HTTP/2 is similarly easy to
> implement with few (if any) corner cases for the framing.
> Framing is just the wrong place to spend complexity... it makes far more
> sense to spend it on features that improve performance, latency, or
> security, at least in my opinion.


Received on Saturday, 31 March 2012 07:14:01 UTC

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