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.)
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.
If Chrome does something different, I wonder why.