Comment by axod | Hacker News Reader

Comment by axod | Hacker News Reader

Support for something like this would be a step in the right direction, but I think there are a couple of simpler ways to improve HTTP:

A similar peeve of mine is HTTP headers.

If a browser opens a connection to a web server, and the connection is keep-alive, the browser will send several requests down than one connection.

But for every single request, it'll send out it's full headers. That's really wasteful and idiotic. Send full headers when the connection is opened, there is no need to repeat every single time.

Also if the connection is keep-alive, it'd be reasonably simple to have gzip compression over the full data - not per request. This would achieve the same as the google proposal, but in a better way IMHO.

The HTTP headers can add up quite a bit if you're using XMLHttpRequest or similar. Also if the data is small, compression isn't worthwhile. HTTP header spam is a PITA.

So if I had my way:

* Headers only sent once at the start of a connection, not per request. Send them if they change - eg a new cookie has been set since the last request :/

* A new transfer-type to specify that the data is gzipped as one - instead of gzipped per request.

Those 2 simple changes to HTTP would make things so much better.

I don't know, these seem like optimizations in the wrong places.

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.

Those are interesting changes.

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?

The main gain with headers would be for comet like applications. In Mibbit/Meebo etc type applications you're sending a lot of small messages, interspersed with HTTP header spam. Often the data is smaller than the HTTP headers.

For gzip, I don't see an issue. The only change that would be needed would be for the gzip state to be saved between requests. For the browser, it would request object A, get the response, unzip it, display. Then it would request object B, unzip it using the previous gzip state, etc.

For the sender, likewise. So there would be no change in terms of timing. The only change would be that the gzip state would be carried over to the next request. (It's possible I'm remembering wrong and gzip can't do this - if so a different compression method that can be compressed/decompressed individually, but using a running shared dictionary/state would be needed).

Comet optimizes for latency, with the big improvement of avoiding the latency of opening a TCP connection and sending the request.

With both long polling and streaming you could probably send the headers long before the actual data is ready to be sent as well.

Reply on news.ycombinator.com