SPDY on Rails(blog.bugsnag.com)
blog.bugsnag.com
SPDY on Rails
http://blog.bugsnag.com/2012/08/05/spdy-on-rails/
16 comments
They 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...
This 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.
SPDY benefits everyone who uses it, not just Google.
You seem to not notice the elephant in the room, being the mandatory TLS encryption.
You seem to not notice the elephant in the room, being the mandatory TLS encryption.
What's wrong with mandatory encryption? Do you still use rsh to log in to your servers?
What'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?
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?
Those 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.
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.
Does 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 ;)
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 ;)
Just 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.
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.
As 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).
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).
You 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.
Partly 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.
So we should make encryption mandatory for the browser to endpoint connection, and optional elsewhere?
My 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.
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.
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.