Re: Backwards compatibility

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.

+1

Willy

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