You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
@Velocio
I was basically serving the SSL version of the site from only 2 domains.
Trusted content came from lfgss.com
Untrusted content came from sslcache.se
Because of the way in which SPDY works, effectively optimizing per domain, there were fractional speed improvements as a result of my only using 2 domains. There would have been little to no benefit if I wasn't reducing the number of domains contant came from.
I effectively proxied ALL third party content (mostly images) through https://sslcache.se and SPDY was enabled on that domain.
However, there is a weird bug going on. The bug didn't affect lfgss.com but did affect sslcache.se .
I'm not sure yet the root cause, but it seems that when SPDY was enabled for the domain that wasn't serving the page itself, that requests in the browser would queue normally, and then one of them would block. At which point, the browser would wait and eventually timeout and abort the connections.
The servers were fine, this was the browser aborting the connections. And it only happened when SPDY was used to serve assets and the assets were not on the same domain as the page.
LFGSS without SPDY, sslcache.se without SPDY = works.
LFGSS with SPDY, sslcache.se without SPDY = works.
LFGSS without SPDY, sslcache.se with SPDY = does not work.
LFGSS with SPDY, sslcache.se with SPDY = does not work.
That said, as this really impacted people for a week and the implementation is identical on both LFGSS and sslcache.se, I was left feeling uncertain about SPDY and thinking that the nginx implementation may have some bugs in it still (it is only in beta). Hence, it's disabled on LFGSS too now.