> We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data?
The commonly-cited reason for pursuing header compression is making the very first request of a session, when your initial congestion window is small. The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs.
Reducing duplication is great and will help for a lot of cases as well, but my impression from the WG has been that it's less important than that first round trip.
Note also that HPACK is really quite efficient in terms of CPU cycles. It takes relatively few to compress the headers very heavily.
Finally, if you really don't like it, you can turn HPACK off. That gives an out for constrained devices that genuinely can't spare the cycles.
> Does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2.0" with an HTTP/1.1 OK response at present.
Yes, because there's a draft spec. I invite you to read it[0]. The summary is that you have three options:
1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. 2. For HTTP/2 over TLS you use ALPN, a feature of TLS that lets you request a protocol in the TLS negotiation (to avoid an extra round trip). 3. Alternatively, you might be able to use HTTP Alternative Services (a WIP draft).
The behaviour Apache is using is clearly a bug.