How to compress HTTP response headers?

Question

At the Velocity 2010 conference, Google said that header compression can yield big gains:

Hölzle noted a glaring inefficiency in the handling of web page headers, which provide information about a user’s IP address, browser and other session data. The average web page makes 44 calls to different resources, with many of those requests including repetitive header data. Holzle said compressing the headers produces an 88 percent page load improvement for some leading sites.

How does one ensure that the response headers sent by the web server are compressed? Is this even possible with today's technology?

Answer 1

Having HTTP request headers or response headers compressed is not HTTP 1.1 standards compliant.

That being said here is some analysis into how such a scheme could be made:

1) Maybe they mean you can accomplish that using some other custom http scheme, like say httpc://.

I could also make a claim that sending requests and responses to/from the same server in batches of 5 increases the speed of the web as well. I call this scheme httpBrian://.

2) If you assume they mean only HTTP response headers, in the request headers you could have another header which specifies that you want the response in as a non compliant HTTP response. I imagine this would have problems with proxies and etc. though.

3) If you assume they mean only PARTIAL HTTP response headers, then the HTTP server could put the non proxy headers that are not immediately important except to the http client performing the request compressed into another header. The HTTP request would enable such a feature. This is most likely what they are trying to accomplish.

Answer 2

Read the paragraph more thoroughly! Hölzle talks about web page headers not http headers. So we talk about something like meta tag and so on.

Ok, it seems, even though I've been downvoted (correctly) a lot, I am the first to find the correct sources. It's about a new application layer protocol named SPDY (SPeeDY get it?) by Google, which offers HTTP header compression.

Answer 3

If the infrastructure supports header compression through some type of custom transport protocol, then it would be compressed all the way until it was handed off to an entity that didn't support that feature.

In the end, perhaps even our browsers would support it. So I think they're taking a proactive approach by starting it on the server end and seeing how far it goes.