Hacker News Reader

Comment by edu | Hacker News Reader

It's a good improvement over HTTP 1.1 and it's nice how they did it in a completely transparent way. Now it's time for the other browsers to support it and to implement way to hint the usage of spdy (maybe a <link rel="" in the first HTTP request, or an extra header in the HTTP request).

View on HN

The link tag is part of HTML, not HTTP. Lots of things besides HTML are transmitted via HTTP.

The protocol belongs in the URL like spdy://google.com but this is not backwards compatble.

So what? There's a long history of <link> elements being used for such things, along with the http-equiv attribute for <meta> elements.

Switch to SPDY needs to be done on lower level than HTML, and HTTP/1.1 even happens to have dedicated feature for such case: the `Upgrade` header:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...

Have you not followed any of the development of the WebSockets protocol and its eventual retraction? It was originally fairly simple and used the Upgrade header that was specified for exactly this sort of thing. Unfortunately, since nobody really used it before, broken implementations in proxies are widespread making it impossible to use without opening up security vulnerabilities.

Sure, http-equiv could be parsed out by the webserver or a proxy and transformed into real headers, but since none of them bothered to do that, the browsers parse them. The end result to the user is largely the same (just that you're unlikely to successfully get a 304). Expecting proxies to do anything intelligent is what's "fundamentally incompatible", not http-equiv.

Right, I forgot that `Upgrade` header requires reuse of the same TCP/IP connection.

It looks like SPDY designers knew what they were doing when they picked custom `Alternate-Protocol` header.

Still, an HTTP header for advertisement seems to me a much better solution than tying protocol negotiation to a markup language (what if I have image-serving CDN or JSON-spitting API?)

I see in spdy-dev archives that SRV DNS records were also considered.

Now it's time for the other browsers to support it

Nope, that time would be when there is an RFC

Pretty much. Looking at it, there's a lot of things that need to be fleshed out before it's actually ready.

EDIT: The main concern I have over this is that it basically forces a state into an already stateless protocol. Streams need to be established, which means that they need a state(up/down/in-between), and both the server and client(browser, in this case) needs to maintain it.

For example:

1. Should the protocol allow browsers to combine streams? I.e. if a user is accessing 3 different youtube videos in HTML5 mode, can the browser do 1 stream for the various static elements on the page, and 3 or more streams for the video and other content?

This can make the browser feel faster even when loading non-cached pages, so it's definitely desirable. However, it's a lot more work on both the browser and the server to maintain it.

2. What rules are there for streams? The draft states that 1 HTTP request and response should be used per stream, but would it make sense to allow the browser and server to assign streams? How are browser-instantiated streams different from server instantiated ones? Do those need any additional rules?

3. Should SPDY be content agnostic(where a stream is a stream), or would it make sense to have several QoS levels assigned to them(i.e. high for video or other streaming data, medium for control, low for static elements)?

4.(related to 3) Does HTML, CGI, etc. need to be extended to handle this, or should it be left up to the server/browsers to implement it?

No, now is the time to make it an option, not ram it down our throats.

As developers, we need to be able to see things exactly as the people we're developing for who do not always have the luxury of using the latest and greatest browsers.

Fuck them. Why should I suffer because some people don't know how to use their computers?

Hey, Jonathan, learn to read. I said "optional" and I meant it. A dev needs to be able to turn certain "features" on and off to model how various types of users are going to experience a site. How difficult would it have been to implement that, instead of just forcing down our throats?

This is the piss poor attitude that kept us stuck on IE6 for 10 years...

This is the piss poor attitude that makes HN a better place. Not that the other comment was the most clever thing I ever read, but please.

Your comment makes little sense; if my piss poor attitude makes HN a better place than why the downvote and snide remark? What is so clever about yours?

You're suggesting that IE6 gave the user options?

Staying there, wallowing in the mud, is an option, though most of us here wouldn't call it a good one.

Waiting for nginx to support it too.

Well, you've plenty of documentation at http://www.chromium.org/spdy just need to push to the IETF.

and get it through the standard process: http://www.ietf.org/about/standards-process.html

The Alternate-Protocol HTTP response header indicates that a server supports SPDY. Then on the second request the client will use SPDY instead of HTTP.

Reply on news.ycombinator.com