6 ms·
Your Chrome browser might not be using HTTP anymore
- kgtm 15y agoIf you want to see your SPDY sessions and an abundance of other related information, browse to about:net-internals from a new Chrome tab.
- edu 15y agoIt'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 agoNow it's time for the other browsers to support it Nope, that time would be when there is an RFC
- edu 15y agoWell, 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 agoand get it through the standard process: http://www.ietf.org/about/standards-process.html http://www.ietf.org/about/standards-process.html
- drivingmenuts 15y agoNo, 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 agoThis is the piss poor attitude that kept us stuck on IE6 for 10 years...
- Seldaek 15y agoThis 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 agoYour 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 agoYou're suggesting that IE6 gave the user options?
- stcredzero 15y agoStaying there, wallowing in the mud, is an option, though most of us here wouldn't call it a good one.
- jrockway 15y agoFuck them. Why should I suffer because some people don't know how to use their computers?
- drivingmenuts 15y agoHey, 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 agoPretty 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 agoWaiting for nginx to support it too.
- chc 15y agoThe link tag is part of HTML, not HTTP. Lots of things besides HTML are transmitted via HTTP.
- blasdel 15y agoSo 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 agoHave 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 agoRight, 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 agoThe Alternate-Protocol HTTP response header indicates that a server supports SPDY. Then on the second request the client will use SPDY instead of HTTP.
- igrigorik 15y agoFor those interested in playing with SPDY, ruby parser and generator: https://github.com/igrigorik/spdy https://github.com/igrigorik/spdy
- uriel 15y agoAn SPDY implementation was recently added to the development version of Go's standard library. (Not surprising given that agl is also part of the Go team at Google.)
- deleted 15y ago[deleted]
- Erwin 15y agoYou can peek into your Chrome'ss current SPDY connections (and other interesting internals) in their internal pages: chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
- ck2 15y agohttp://google.com/search?q=site%3Aycombinator.com+spdy http://google.com/search?q=site%3Aycombinator.com+spdy
- tiles 15y agoThe transparency with which Chrome did this was actually a problem for me. Google Docs/GMail did not work for months on my school's ethernet connection until I read about SPDY being implemented; sure enough, launching Chrome with SPDY disabled fixed the issue, and that requires a command line option. I wish Chrome were less transparent about this and added a few Preferences options, at least.
- tyler 15y agoI don't mean to be pedantic, but the word "transparent", in this context, means "easily perceived or detected". I believe you're using it to mean the opposite.
- solarmist 15y agoNot to be pedantic, but your message should read, "I know I'm being very pedantic, but ..." :P
- jmillikin 15y ago> the word "transparent", in this context, means "easily perceived or detected" This definition doesn't make much sense to me. Transparent objects are less easily perceived/detected than opaque objects. In technology, transparent proxies/compression/encryption are designed to have little/no impact on their contained data.
- BCM43 15y agoI think this word uses the assumption that between you and them is an object. If the object is transparent, you can see what they are doing. If it is not, and it is a cloak of some sort, you cannot see what they are doing.
- delinka 15y agoAgreed: "this feature works so transparently that I didn't even know it was there" Not knowing was a bad thing in this case.
- 15y ago
- joejohnson 15y agoDoes Apache support SPDY?
- wmf 15y agohttp://code.google.com/p/mod-spdy/ http://code.google.com/p/mod-spdy/
- strictfp 15y agoReally annoying that they didn't just use SCTP. One commenter on the page points out that it works on top of TCP, which is supported by most routers. This, however, is an entirely artificial limitation. It is a sad fact that this type of artificial restrictions are imposed, and i say that we should fight against them. Having all inet services running over port 80 and TCP does not make the net any safer or better. We as hackers should fight for making people aware of and remove such restrictions, not accept and worsen the crippled situation by working around the problem. This is one of the key problems in the digital world today, too few actually makes an effort to fix the underlying problems. Here Google could play a crucial role, and I must say that I am dissapointed by their choice.
- sipior 15y agoI'm afraid I don't understand this. SCTP is a transaction-level protocol, whilst SPDY works at the application layer, does it not? These choices are orthogonal, not mutually-exclusive, as near as I can tell.
- wmf 15y agoHTTP over SCTP would bring many of the same advantages as HTTP over SPDY over TCP.
- sipior 15y agoRight, that was the part I did understand :-) What I didn't get was why the parent comment was disappointed that Google didn't choose SCTP over SPDY, since no either-or choice is required here. Couldn't SPDY be run over SCTP as well (leaving aside the problems with SCTP that you brought up in your previous comment), albeit with some redundant functionality?
- wmf 15y agoIf SPDY were designed to run (only) over SCTP, presumably the redundant functionality wouldn't have been designed in the first place, saving Google's time and yielding a more elegant protocol. At least that's my interpretation.