4 ms·
SPDY on Rails
- jvehent 14y agoThey forget to explain what problem they are trying to solve. SPDY will benefit google in the race for 100ms response time. For the rest of us, HTTP does the job. But without the hype effect, I suppose...
- stanleydrew 14y agoThis is a strange comment. SPDY benefits everyone who uses it, not just Google. And actually, for any site with authentication plain HTTP does not do the job, since all requests that pass authentication information should be encrypted. So HTTPS is a requirement and if SPDY can help make HTTPS faster then everyone wins.
- xyzzyz 14y agoSPDY benefits everyone who uses it, not just Google. You seem to not notice the elephant in the room, being the mandatory TLS encryption.
- jrockway 14y agoWhat's wrong with mandatory encryption? Do you still use rsh to log in to your servers?
- xyzzyz 14y agoWhat's wrong with mandatory encryption? Some people say that it uses too much computational resources, for instance. Others complain that mandatory TLS increases latency by one additional RTT. Mandatory TLS is a biggest point of conflict at the IETF discussion about SPDY being the HTTP successor (at least from what I heard), though many sides disagree for evil reasons. Do you still use rsh to log in to your servers? Does this question add anything of value to the discussion?
- jrockway 14y agoDoes this question add anything of value to the discussion? Yes. If you are the "I hate encryption because it messes with my tinfoil hat" type, you'll get all angry and not reply. For anyone else, the question is just a minor annoyance to wade through ;)
- harshreality 14y agoThose people are living in a fantasy world where governments or ISPs do not care about what their citizens or customers are browsing and are not doing wholesale traffic proxying/collection. In that fantasy world, it's rare for companies who should know better to serve login pages over insecure connections. SSL also prevents doing MITM to serve malicious content to browsers to exploit browser or plugin vulnerabilities. Universal SSL would mean attackers would have to get you to visit their site, or a site that includes content that they control.
- jvehent 14y agoJust because some poorly trained engineers don't understand the concept of security should not force the rest of us to use strong, and slow, encryption. Encrypting the wire should only be used to solve very specific problem. Often, encrypting the data in the application, and transmitting over cleartext http, is better. I understand those concepts, and that why I don't want SPDY to force me to use TLS everywhere. It's just overkill and cumbersome.
- MikeCapone 14y agoAs a user, I mostly like SPDY because it makes HTTPS better (not perfect, but better than what was there before), and I wish more sites used an encrypted connection by default. Anything that brings us closer to that is desirable, IMO. That's mostly out of principle -- I just wish there was less plaintext info swirling around the net. For some people it could be a life or death benefit (ie. civil right activists in repressive countries), but for me personally, it's mostly an aesthetic pleasure (I enjoy the idea of more secure communications).
- xyzzyz 14y agoYou may find interesting the fact that most of the IETF basically agree to base HTTP 2.0 on SPDY, with those disagreeing being mostly Microsoft delegates voting for Microsoft's S+M proposal.
- jvehent 14y agoPartly true. I found the discussions on solving the cookie problem, with better session mechanism, and using binary header that are not encrypted, to be extremely interesting. Using encryption everywhere just because we should is dumb. What will happen is that we'll enforce a TLS handshake and use a NULL algorithm. Mandatory encryption will just make load balancing so much slower, and only 5/10% of the HTTP traffic inside a datacenter really deserves to be encrypted.
- tonfa 14y agoSo we should make encryption mandatory for the browser to endpoint connection, and optional elsewhere?
- stanleydrew 14y agoThis isn't really about Rails at all. But it's still useful as another anecdote about how SPDY is used in production. Basically if you are set up with the now-fashionable architecture of a caching reverse proxy serving static content (nginx or Apache) sitting in front of a set of application servers then this applies to you too. Just compile nginx with the SPDY patch or use mod_spdy with Apache and your back-end application servers won't even need to know what the transport protocol between client and reverse proxy is. It will be handled transparently.
- AhtiK 14y agoMy problem with SPDY is that it is compressing only headers. I still haven't figured out how to combine SPDY and gzip compression for POST requests without manually decompressing it in the browser javascript. Other than that SPDY is extremely useful for web apps as the latency with HTTP round-trip is noticeable and most of the cases web app already runs behind TLS. For a regular website (not a web app) SPDY adds much less value: 1) TLS encoding and negotiation adds load time 2) 3rd party javascript loading from HTTPS sources do the same 3) Main server data that was previously sent gzipped is now sent deflated [1]. [1] Maybe it's just my incompetence and it's easy to compress the SPDY content. Would be happy to hear about it.