I may be mistaken, but since everything in SPDY happens over a secure connection, isn't caching already broken? It seams to me that any approach to combining resources to minimize round-tripping will involve a trade-off against the granularity of caching properties.

I think the source of the confusion is that you are conflating sharing of a [SPDY] connection with sharing of a resource identifier (a URI/URL). This is a misunderstanding. SPDY multiplexes multiple streams over a single connection (or more accurately, a session). Each stream is used in the HTTP layering case to correspond to a request/response pair for fetching a resource at a URL. So, even though a single connection is shared, different resources at different URLs can be simultaneously requested over the same SPDY connection.

In short, SPDY does not imply combining resources. Application level combining of resources is a common hack to work around lack of parallelization at the HTTP/1 protocol level, but as noted, it has deficiencies.

I'm aware of the distinction. However, part of the goal of SPDY is to avoid round-trip by pre-emptively sending resources. So the question still remains, why not use some type of archive format to send the HTML along with the images and other assets that would have been pushed down the pipeline? Clients could negotiate for the bundle using Content-accept, and proxies would not be broken.

Nope. Caching proxies aren't possible, but the browser cache still works fine.

It seems to me, it wouldn't be that hard to make up a header that says, "Hey, you're GETting '/'. If so you'd probably also like to GET …" Then you send a list of which of those URLs you want (while the HTML for '/' is still being sent), then it sends the rest of the files as one big old MIME blob.

Then again, I don't know much about HTTP, so maybe I'm missing something obvious.

Edit: Hmm, just learned about SPDY's server hinting, which is pretty similar to my idea.