Hacker News Reader

Comment by rwj | Hacker News Reader

I wonder why no one has defined a multi-part message format. The server would deliver a single file, which would start with the HTML and be followed by images and other assets. This approach should play nice with all the proxies (which would see a single octet stream), and, since the pipelining multiplexes everything on a single connection anyway, deliver similar performance.

I understand that no one wants to define a new format, but I don't see how it is more difficult than defining a new protocol.

View on HN

While intriguing, this suggestion has a number of issues. For one, it implies coalescing a number of resources into a single resource named by a single URL. This means that all resources would have to share the same caching properties. Since it's generally desirable to keep the main document (the HTML) uncacheable to allow site updates, this would imply eliminating the vast majority of web caching, which sounds undesirable.

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.

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

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.

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.

It's called MIME. email does it everyday. Why it's never been applied to HTTP is beyond me.

Check out RFC 2557. You can send MIME encoded resource bundles down to IE 5.0+ clients and they will render it just fine.

Reply on news.ycombinator.com