Hacker News Reader

Comment by wmf | Hacker News Reader

My understanding is that HTTP/1.1 pipelining can break in a messy way where the client isn't sure whether some requests in flight will be serviced or not. Thus it tends to be disabled. In contrast, SPDY either works correctly or it falls back to regular HTTP.

View on HN

There are some problems in HTTP pipelining. Nevertheless Firefox and Opera have pipelining implementations that work and are significantly faster than HTTP with keepalive. It's enabled by default in Opera.

The point being that they've designed this new protocol based on their assumptions and hunches. Same lack of rigor is present throughout the whole spec -- take a look at how much redundancy is in the prefix dictionary for instance.

http://www.chromium.org/spdy - contains some great and in-depth research motivating SPDY.

Original whitepaper: http://www.chromium.org/spdy/spdy-whitepaper

Here's a good tech talk to checkout as well: http://www.youtube.com/watch?v=TNBkxA313kk

Draft 3 has also updated the dictionary, here's the research paper motivating the change: http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf

Chromium and Chrome Dev Channel has (off by default) pipelining.

Pipelining can only be done for idempotent requests, (ie GET only), has head of line blocking problems, and can break proxies.

Also, its very difficult to handle errors in a pipelined situation. For example, if the 2nd request in a pipeline fails, but the server has been processing 3rd and 4th concurrently, what response does it give?

I think most engineers would agree that multiplexing over a single connection is better and less error-prone than pipelining.

Reply on news.ycombinator.com