Agreed. I think a great option would be for the server to specify in a response header that it doesn't care about any headers for the rest of the keep-alive connection, unless they change.
I've been getting into comet a bit more lately, and am wondering (if you don't mind telling of course) 1) what you are currently using on the backend and 2) if you ever checked out Meteor (which I was playing with today)?
I decided to write my own. Gives me much more flexibility and am able to change, adapt, streamline the backend as much as I like. (Java nio) It peaks at about 10k connections at the busy times at the moment (incoming and outgoing). The backend code is about 22k lines of code, but that's everything - not just the base comet server.
I did have a look at Meteor and some of the other comet type servers but they didn't look like they would be a great solution for what I needed.
It would be much better still for them to implement WebSocket: this is a marginal optimization at best, while adopting WebSocket would be a fundamental improvement and would much more significantly reduce bandwidth, etc.
I'm not sure it's marginal though. Consider a site that has a gallery of 100 thumbnails, each one say 200 bytes in size.
With firefox3, the browser would have to send 49,500bytes of HTTP headers just to get those 100 thumbnails which are only 20,000bytes in size. That's a ridiculous overhead. Even if you're using deflate or gzip, that's only gzipping the 20k data, not the 49.5k of headers.
Google has already proposed a gzip content compression scheme that could operate over a number of pages.
It would also be feasible for them to come up with a header compression scheme - perhaps even in Chrome first.