3 ms·
SPDY is built on top of TLS, which means it requires a site to have a valid SSL certificate in order to work. This, unfortunately, limits SPDY only to CloudFlar
by joubert 14y ago
SPDY is built on top of TLS, which means it requires a site to have a valid SSL certificate in order to work. This, unfortunately, limits SPDY only to CloudFlare's paid customers who have enabled Flexible or Full SSL support. Microsoft is working on revised IETF proposal that is SPDY-like, but removes the requirement for SSL/TLS. If the TLS requirement is removed in the future, we'll make SPDY (or whatever it comes to be called) available more broadly.
Can SPDY theoretically be transitioned to not be built on top of TLS, or is the MSFT work a more likely solution?
- jgrahamc 14y agoOne of the reasons SPDY is on top of TLS is so that equipment between the browser and the server doesn't try to mess with the protocol. If SPDY were run on port 80 then there would be problems with proxies etc. Wrapping it in TLS means that it can't be snooped upon and messed with.
- afimrishi 14y agoSPDY as specced does not require TLS. However, you can see Google's WebSocket connectivity test results at http://www.ietf.org/mail-archive/web/tls/current/msg05593.html http://www.ietf.org/mail-archive/web/tls/current/msg05593.ht.... The poor connectivity over ports other than 443 is one of the strongest motivations for real deployments of SPDY over the public internet to require TLS.
- mdwelsh 14y agoSPDY does not technically require TLS, but It's the Right Thing To Do [tm]. According to Mike Belshe, there are two reasons that SPDY was designed to use TLS. The first was pragmatic: Middleboxes on the Internet wouldn't be able to pass through non-HTTP traffic, so unless a different port was used, the only way to punch through the various proxy layers was to use end-to-end security. But the other reason is just as important: It's 2012, folks. It seems insane that most Web traffic goes in the clear. Browsers are fully capable of doing the SSL handshake without incurring a major performance cost - even on mobile devices. Finally, we may not get another chance to change the web protocol stack for another 15 years, so it's best to get it right now.