Well actually the HTTP connections are stateless, but not the SPDY connection. SPDY connection keeps the session open between two endpoints and do have the knowledge about the other streams. That's what makes it possible to do server push or header augmentation.
Could somebody clear this up for me (I've seem to forgotten it): I know you can run a HTTP and SPDY "versions" of your webpage in parallel. But how does the browser know which protocol to use (if it supports both)? Does it initially make a HTTP request and the server responds with some header that let's it know it can use SPDY or what?
OK thanks. That cleared things up :) Too bad that this means that the first request (which is usually the most expensive one) is always done trough HTTP :/
Not really. The HTTPS requests can choose SPDY using the Next-Protocol-Negotiation(NPN).
Alternate protocol header would matter only to HTTP requests to know this server is capable of supporting SPDY. However, as per the latest post by Opera Labs[1], all 3 major browsers supporting SPDY doesn't handles this header correctly. Also, it's not mentioned in SPDY draft 3.
Any expert ready to venture a guess on how fast SPDY could be adopted by most of the biggest websites on the net? Could it spread like wildfire when all the main browsers and web-hosting softwares adopt it, or are we talking about years and years (like getting rid of IE6)?
I hope it will be the same story as HTML5 (IE will took it after everyone)
And SPDY will spread much more higher rate than HTML5.
Because it is a little work to be performed at the website end not like HTML5.
Hope within 1 year, it will be in a state where HTML5 today.
SPDY requires SSL and SSL for all intents and purposes doesn't work with name based virtual hosting (it doesn't for all versions of IE under XP and on Android < 4) due to the lack of SNI.
Aside of a noticable hit in performance for the encryption work (some say insignificant which is probably true if you are google), enabling SSL is a considerable additional administrative hurdle both because of getting certificates (and keeping them fresh) and because of the requirement of needing one IP per domain.
The latter problem is going to get worse as more sites want to go SSL and we're already out of unassigned IP addresses.
If only we could have widely supported SNI. Then we'd back at only the performance issue (which is going to get less and less noticeable as our hardware gets better) and the administrative overhead for the certificate.
Their DNS is broken. They have a CNAME at the root of their zone, which is forbidden. If you're using the "Unbound" DNS resolver (I am), and it's in DNSSEC validation mode, then it will SERVFAIL when it comes across broken DNS like this (even if the zone isn't using DNSSEC).
I don't know about other DNS resolvers, but IIRC didn't Comcast switch to using resolvers which support DNSSEC for their customers recently?
[edit] - Can you see http://imgur.com/ on Comcast? That (well known) site has the same problem. I tried to alert them to this fact a few weeks ago but never heard back. I'd be surprised if Comcast users can't access that site.
That's not what stateless means. And unless I am gravely mistaken, HTTP over SPDY is still stateless.