Proposal: Multipart Web Requests

Here’s a little idea that might improve the web for everyone. I don’t know how to draft or submit a Request For Comments—I could have read RFC 2026 (BCP 9) but I wasn’t interested—but if anyone would like to see this through, I hope you’ll contact me.

We could improve the overall performance and reduce the request load on most of the world wide web if servers supported a way of sending in one response some or all of the resources that will certainly or likely be requested (GET) as a result of parsing the requested resource.

A sufficient implementation might be possible using existing RFCs. Perhaps a media range of “Multipart” in the Accept request-header field could be used to announce that the client can accept such responses.

The ideal implementation might include optimizations for client and proxy caches, such as a Cached request-header whose value would specify for exclusion from the response any already-cached items and their LastModified, ETag, or other conditional request-header values as appropriate.

Static files served in this manner might be parsed by the web server in order to discover which, if any, other resources (images, audio, stylesheets, DTD’s, etc.) should be sent. The server might take cues from a saved list, as from a cache of previous results of parsing or from a manually generated list.

Servers generating resources dynamically might take cues from the program state, or the page generation scripts might cue the server by passing data directly or as a value of an Include response-header. When a proxy detects the Include response-header along with a single-part response, it may assume that the server was incapable of providing a multi-part response and convert the response into a multi-part response if the proxy has a valid copy or wishes to pre-fetch a copy of any or all of the resources indicated by Include.

A typical request might proceed in this way:

1. Client requests /index.html from example.com with Accept: Multipart
2. Server finds index.html and discovers that its display will require a PNG file as a background.
3. Server responds:
   {response-headers}
   {body-part (text/html)}
   –boundary
   {body-part (image/png)}
   –boundary–

In the preceeding example, there is no explicit request for the background image but the client receives it in the payload of the initial response.

Specialized user agents may use the Accept request-header to specify which types of media they prefer to receive but there ought to be a way for agents to specify which types of media they prefer not to receive in multi-part responses. For example, a screen reader probably would want the server to bundle audio but not images. A Reject request-header could indicate unwanted media types or a zero q-value in the Accept header might serve to prevent the server or any proxies from attaching these types.

A proxy handling a non-multi-part request from a client may request resources in multi-part mode and then cache and serve the individual parts as if each had been requested singly. Proxies may construct multi-part responses from parts retrieved individually and they may append additional parts according to any cue, such as by rendering web pages with the engine of their choice (perhaps taking a hint from the User-Agent request-header).

The existence of an entity in a multi-part response should not cause the user agent to display, execute, or otherwise handle the entity. User agents accepting multi-part responses should not store or execute any part which was not used during the course of rendering or interacting with the requested resource.

Does anybody else think that something like this could be beneficial?

Tags: HTTP, IETF, RFC, WWW