4 ms·

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 i

by edu 15y ago

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).

Angostura 15y ago
Now it's time for the other browsers to support it Nope, that time would be when there is an RFC
- edu 15y ago
  Well, you've plenty of documentation at http://www.chromium.org/spdy http://www.chromium.org/spdy just need to push to the IETF.
  - protomyth 15y ago
    and get it through the standard process: http://www.ietf.org/about/standards-process.html http://www.ietf.org/about/standards-process.html
- drivingmenuts 15y ago
  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.
  - djroketboy 15y ago
    This is the piss poor attitude that kept us stuck on IE6 for 10 years...
    - Seldaek 15y ago
      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.
      - djroketboy 15y ago
        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?
    - pyre 15y ago
      You're suggesting that IE6 gave the user options?
      - stcredzero 15y ago
        Staying there, wallowing in the mud, is an option, though most of us here wouldn't call it a good one.
  - jrockway 15y ago
    Fuck them. Why should I suffer because some people don't know how to use their computers?
    - drivingmenuts 15y ago
      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?
- cube13 15y ago
  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?
- newman314 15y ago
  Waiting for nginx to support it too.
chc 15y ago
The link tag is part of HTML, not HTTP. Lots of things besides HTML are transmitted via HTTP.
- blasdel 15y ago
  So what? There's a long history of <link> elements being used for such things, along with the http-equiv attribute for <meta> elements.
  - pornel 15y ago
    <meta http-equiv> is not a good design — it was intended to be parsed server-side, but ended up being used on client-side, which is fundamentally incompatible with the way HTTP proxies are supposed to work. 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.42 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
    - blasdel 15y ago
      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.
      - pornel 15y ago
        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.
wmf 15y ago
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.

by edu 15y ago

Angostura 15y ago

Now it's time for the other browsers to support it Nope, that time would be when there is an RFC

edu 15y ago
Well, you've plenty of documentation at http://www.chromium.org/spdy http://www.chromium.org/spdy just need to push to the IETF.
- protomyth 15y ago
  and get it through the standard process: http://www.ietf.org/about/standards-process.html http://www.ietf.org/about/standards-process.html
drivingmenuts 15y ago
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.
- djroketboy 15y ago
  This is the piss poor attitude that kept us stuck on IE6 for 10 years...
  - Seldaek 15y ago
    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.
    - djroketboy 15y ago
      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?
  - pyre 15y ago
    You're suggesting that IE6 gave the user options?
    - stcredzero 15y ago
      Staying there, wallowing in the mud, is an option, though most of us here wouldn't call it a good one.
- jrockway 15y ago
  Fuck them. Why should I suffer because some people don't know how to use their computers?
  - drivingmenuts 15y ago
    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?
cube13 15y ago
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?
newman314 15y ago
Waiting for nginx to support it too.

chc 15y ago

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

blasdel 15y ago
So what? There's a long history of <link> elements being used for such things, along with the http-equiv attribute for <meta> elements.
- pornel 15y ago
  <meta http-equiv> is not a good design — it was intended to be parsed server-side, but ended up being used on client-side, which is fundamentally incompatible with the way HTTP proxies are supposed to work. 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.42 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
  - blasdel 15y ago
    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.
    - pornel 15y ago
      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.

wmf 15y ago

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.