This is not true. Only HTTPS URLs get SPDY. Perhaps you're thinking of HTTP Strict Transport Security, which transforms HTTP URLS to HTTPS on the client. You can see whether you're getting SPDY or not (in Chrome) at chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active

One reason for this is that proxies and other buggy/evil bit-twiddlers in the path of your connection don't understand SPDY, so the only way to punch SPDY through them is to use a protocol they're not allowed to meddle with.

I can't find any documentation to corroborate that. The draft 2 spec mentions HTTP several times: "...it should be used in preference to HTTP/HTTPS. ... all HTTP requests can "piggyback" on an existing SPDY session. ... all future http requests to that host port pair should use the SPDY session rather than opening a new HTTP connection." http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra... (Curiously, the deployment section is completely missing from draft 3 and the IETF version.)

If Chrome does something different, I wonder why.

Interesting, I hadn't seen that part of the spec. Since it was removed from later drafts, perhaps there was some objection. It's clearly not implemented on google.com.

Edit: Chrome and Firefox do appear to contain support for the Alternate-Protocol header described in Draft 2 of the spec, so it does appear possible to configure your server to tell them to send HTTP:80 requests over SPDY:443 instead. However, this does not allow one to use SPDY without encryption, and it does not add significant security to plain HTTP since the first request is still unencrypted.

After further research, while Alternate-Protocol is implemented, it appears that it might not end up being standardized due to security concerns. I wouldn't rely on it.

It looks to me like it's just talking about HTTP the protocol, as in GET, POST, etc., and saying that you can reuse a SPDY session instead of opening a new connection — it's not saying you can use SPDY over unencrypted HTTP.

As I said, SPDY always runs over TLS. What we're debating here is whether you can request an http: URL over a (secure) SPDY connection. I see no reason why not and it should be faster, yet it appears that this isn't being done.

We removed the alternate-protocol stuff only because we thought it needed more work. It is implemented in chrome, so you can try it, but we're still considering how we'll deal with it going forward.