Would zipping a file take too much time? Is it possible to zip-compress each file beforehand, then use scripts to combine the file pieces together with some zip headers and footers?
(Yeah, I don’t know exactly how zipping works.)

The idea of downloading an entire zip file over again when something changes is terrible. That has to have a work-around.

This would guarantee adoption of this proposal WITHOUT needing anyone to change any of their pages. As soon as the HTTP server is upgraded all customers with upgraded browsers will see the performance benefits.

Web servers would become responsible to generate another HTTP header (similar to content negotiation) which defines the resources that the current page depends upon. This would also guarantee that all dependencies are resolved BEFORE the page is loaded.

Example HTTP header:

Accept-package: type=application/zip; href=/pkg.zip;

This approach allows for flexibility in compression types so, for example we could also have:

Accept-package: type=application/gzip; href=/pkg.gz;

Additionally, this scheme would also allow the manifest to be fetched inline. So we don’t have to worry about whether the manifest is first in the zip file or not:

Accept-package: type=application/zip; href=/pkg.zip; manifest=js/jquery.js; js/main.js; css/reset.css; css/grid.css; css/main.css; images/logo.gif; images/navbar.png

Or, if that’s too messy the manifest could be fetched in another href:

Accept-package: type=application/zip; href=/pkg.zip; manifest-href=/manifest.txt

but that would require an extra HTTP request!

Thoughts anyone?

Shiraz

HTTP can already gzip-encode any document at the transport level. Besides some brokenness in CSS and JS decompression that’s mostly history in IE (IE6 is history, isn’t it ?), we take for granted that we can deploy (or dynamically generate) any plain text file on a web server and let the HTTP server gzip it. I can’t see the CPU and memory impact of gzipping on my servers today, it’s a tiny fraction of any work of a frontend. And it’s a great and automatic benefit for everybody and strategic types of document.

HTTP could also solve the problem of fetching multiple documents at once. The whole idea is to spare round time trips, isn’t it ? We could preserve all HTTP semantics (one URI per document, caching, headers, etc) if we could send a HTTP GET which bundles many URIs and expects for instance a MIME encapsulated response with headers+body for every requested document.

I don’t think that could be handled by globs like ‘GET /*.js’, this would be to complicated to specify and implement (the browser would not know distinct ressource names in advance for a start). And obviously that would have to be somewhat URL-encoded to reuse all the infrastructure we have. Maybe is not that crazy.

The bundle.zip has the advantage of letting the developper explicitly choose and name what’s bundled together. With a ‘multiple document’ GET request, we would have to let the browser decide how to bundle requests (alhtough it might be smarter than a webdev on average :)).

It also only leverages client-side support and no protocol changes. Obviously this is way easier to implement and foster.

The bundle.zip has the disavdantage of providing poor or no metadata: zip will store the mdate and that’s pretty it, nothing like HTTP headers. That could be painful: for bundles, the browser will map an extension to a MIME type, which will not be necessarily the same mapping as the one picked by the server. Going back and forth between single and bundled ressources will not be always easy and transparent.

Support for “Get multiple” would require basically the same basecode as MHTML on the client side I guess. On the server side this is a kind of ‘HTTP pipelining’ but without the async nightmare of it: there’s one session for many documents, but first client talks, then server answers, and done. The server side can be prototyped easily with a simple CGI.

@Kyle: Most of the discussion has been around inlining the manifest.txt in HTML. Doing it as header would work, too.

V. General Format of a .ZIP file
Files stored in arbitrary order.

There are probably ZIP compressor clients that allow you to specify which file comes first in the library, but doesn’t this make the whole idea a lot more complicated. Wouldn’t it be better to just include this information in the HTML itself.

Adding this manifest.txt as a separate file doesn’t seem smart, since it would then introduce yet another HTTP request.