SPDY doesn't provide a way to proxy-cache public assets, so it's bad for places that use such caching to mitigate low bandwidth / high latency connections.
which is to be expected with a TLS connection. OTOH you get to drop all the extra TCP handshakes, you get better congestion control, you get header compression, and that encrypted connection is often a really good thing.
Transparent caching is part of what makes http so great. Security is relative, you can authenticate content without encrypting it, if there is nothing sensitive about the content.
The authentication can happen external to the http or spdy transaction as well.
> you can authenticate content without encrypting it
True, but insecure HTTP provides neither authentication nor encryption.
> if there is nothing sensitive about the content.
Encrypting only sensitive content leaks information to observers and attackers, namely when you transmit sensitive content, and which servers you connect to when you do so. Encrypting all content eliminates that information leak.
Wouldn't this be solved by sending a
Cache-Control: public, max-age=<long-duration-in-seconds> header so that the assets can be stored in ISP proxy caches as well as browsers on-disk caches
I'd consider that a feature, not a bug. Transparent proxies considered harmful, especially when done without informing their users.
A SPDY client that trusts a particular proxy could easily allow that proxy to operate on its behalf, and SPDY would actually make that far more efficient.
