4 ms·

HTTP/2.0 already exists. It's called SPDY. The IETF really dropped the ball here. People have been complaining about HTTP's problems for over a decade, but the

HTTP/2.0 already exists. It's called SPDY. The IETF really dropped the ball here. People have been complaining about HTTP's problems for over a decade, but the IETF couldn't even come up with a standard. Usually the problem is adopting a standard, not creating it. Lately, it seems like standards bodies are lagging. The W3C has a similar problem. Browsers implement new CSS properties. Eventually, the W3C picks the standard name for the new CSS property. I'm betting something similar will happen with HTTP/2.0. Eventually, the IETF will approve SPDY as the new standard. A side note: It used to be that browsers wouldn't add support for a new protocol because web servers didn't support it. Web servers wouldn't add support because browsers didn't support it. Now that Google has a significant chunk of the browser market and serves a significant chunk of web traffic, they've solved this chicken-and-egg problem. They can coordinate roll-outs, then let everyone else play catch-up.

naner 14y ago
SPDY is likely not our savior (from the Varnish author): http://developers.slashdot.org/story/12/07/13/1327235/varnish-author-suggests-spdy-should-be-viewed-as-a-prototype http://developers.slashdot.org/story/12/07/13/1327235/varnis... Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic. His full writeup is quite good, I'm not sure that if it was submitted to HN: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html
- AngryParsley 14y ago
  That guy doesn't make much sense. He's worried about scaling? SPDY can scale. Google uses it. Then he complains about security and complexity, but he wants people to seriously consider mixing HTTP and HTTPS in the same TCP connection?! There's a reason every browser complains about mixed content by default.

naner 14y ago

SPDY is likely not our savior (from the Varnish author): http://developers.slashdot.org/story/12/07/13/1327235/varnish-author-suggests-spdy-should-be-viewed-as-a-prototype http://developers.slashdot.org/story/12/07/13/1327235/varnis... Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic. His full writeup is quite good, I'm not sure that if it was submitted to HN: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html

AngryParsley 14y ago
That guy doesn't make much sense. He's worried about scaling? SPDY can scale. Google uses it. Then he complains about security and complexity, but he wants people to seriously consider mixing HTTP and HTTPS in the same TCP connection?! There's a reason every browser complains about mixed content by default.