8 ms·
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
by coderrr 18y ago
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?
- axod 18y agoThe 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).
- tlrobinson 18y agoComet 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.