- From: <K.Morgan@iaea.org>
- Date: Fri, 25 Apr 2014 08:55:00 +0000
- To: <martin.thomson@gmail.com>
- CC: <jgraettinger@chromium.org>, <mnot@mnot.net>, <ietf-http-wg@w3.org>, <matthew@kerwin.net.au>
- Message-ID: <0356EBBE092D394F9291DA01E8D28EC20112972E13@sem002pd.sg.iaea.org>
On Thursday,24 April 2014 23:13, MORGAN, Keith Shearl wrote: > >... Although it might be odd for an implementation to mix compressed and uncompressed frames within a segment, > I can think of examples where it might be convenient. Sorry to reply to my own-email, but I wanted to mention a few examples where it might be convenient to allow compressed and uncompressed frames within a segment. These examples may or may not be pathological. Perhaps others with more experience have other examples?? 1) A server under heavy load might want to dynamically switch off gzip frame compression to conserve cpu resources. Allowing a mix of compressed and uncompressed frames within a segment would allow a server to immediately switch from compressed frames to uncompressed frames. 2) Amos mentioned here [1] that intermediaries may want to extract a range from a resource they already have cached. I could imagine a scenario where the intermediary might want to cache the resource with the frames compressed (i.e. as received) to avoid re-compressing for clients which support gzip. To accomplish that the intermediary could index the offsets of the underlying data contained in each compressed frame. When later servicing a range request the intermediary would first find the frame which contains the beginning offset of the range. That frame would likely need to be decompressed to discard the data < the beginning offset. The data from that frame >= the beginning offset could be re-compressed or sent uncompressed. All of the frames in-between the beginning and end offsets would be sent as-is (i.e. compressed). The frame containing the end offset of the range would be processed in the same manner as the frame containing the beginning offset. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0115.html This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Friday, 25 April 2014 08:55:42 UTC