New multi-page HTTP compression proposal from Google

1. Headers aren't always the same for every request. Etags and other cache headers, content-types, etc can/will all be different. They're also comparatively small to most content. And of course you can control which headers you send, so if it's really a problem just send the bare minimum.

edit: I'm talking about the response headers, reading that again it looks like you're talking about the request. In that case you're probably right, there's a lot of duplication, especially user agent and cookies.

2. You don't know every resource you're going to request up front: you download whateverpage.html, decode and parse it, then make all the requests for scripts, images, stylesheets etc. I don't see this working very well.

It's true most headers don't change. One I can think of that usually changes between resource types is Accept. Usually it will be slightly different between <img> <script> <link> and <iframe>, but this probably wouldn't make much of a difference if you allow only to send changed headers. I'd be curious to see how much bandwidth you save with this. You also might want to allow for header removal as you do header change. I can't think of a scenario where not removing a header would cause a problem, but there could potentially be one.

For the gzip as a whole instead of per request, there's one reason I can't see many browsers taking advantage of that. Most browsers will make requests like, write request, read response, write request, read response. Instead of write, write, write, read, read, read. So I'm not sure how you could unzip everything together unless you wait to display the items till the entire connection is finished. Also, this would require the client to give an indication when it is done writing requests to the stream, so that all the data can be fetched from the server and then zipped together. Which would require a much bigger change to the protocol.

Is there anything I'm missing?

"It seems to me that AJAX can be used to solve this problem in a simpler manner. Take Gmail for example--it downloads the whole UI once and then uses AJAX to get the state-specific data. The example from the PPT showed a 40% reduction in the number of bytes transmitted when using SDCH (beyond what GZIP provided) for google SERPs. I bet you could do about that well just by AJAXifying the SERPs (making them more like GMail) + using regular HTTP cache controls + using a compact, application-specific data format for the dynamic parts of the page + GZIP. Maybe Google's AJAX Search API already does that? In fact, you might not even need AJAX for this; maybe IFRAMEs are enough.

I also noticed that this proposal makes the request and response HTTP headers larger in an effort to make entity bodies smaller. It seems over time there is an trend of increasingly large HTTP headers as applications stuff more and more metadata into them, where it is not all that unusual for a GET request to require more than one packet now, especially when longish URI-encoded IRIs are used in the message header. Firefox cut down on the request headers it sends [2] specifically to increase the chances that GET requests are small enough to fit in one packet. Since HTTP headers are naturally highly repetitive (especially for resources from the same server), a mechanism that could compress them would be ideal. Perhaps this could be recast as transport-level compression so that it could be deployed as a TLS/IPV6/IPSEC compression scheme.

Regards, Brian "