[hacst]

The header compression in HTTP 2.0 isn't based on gzip or something like that. The CRIME attack pretty much killed those approaches dead. It's more akin to differential updates for header during the lifetime of the connection. So if you request a lot of files with fairly similar headers you'll effectively only have to transmit the bulk of the header once while the other request will efficiently re-use the previously transmitted fields.

So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.

[dragonwriter]

> So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.

In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.

[stephen_g]

I think this is correct - because that is one big area where TCP and HTTP really fall short.

HTTP/2 should be a huge improvement for lowering latency in anything but the simplest web sites, without having to use ugly hacks such as sprite sheets and putting all your javascript/CSS in one file (which is sub-optimal in terms of caching if you want to update say a single javascript file, because then a user with a full cache has to re-download the huge concatenated javascript file instead of just the single source that changed), and avoiding spanning things across multiple domains to get around browsers having a connection limit.

[ademarre]

Doing many requests over the same connection is very common.

[frankzinger]

And one of the fundamental goals of HTTP/2 was to get clients to create only a single connection to a server.

[patrickmcmanus]

right. The other key fact is that request header compression is necessary to make parallelism work when interacting with tcp congestion control. Its critical.