- From: <K.Morgan@iaea.org>
- Date: Mon, 21 Apr 2014 12:22:32 +0000
- To: <martin.thomson@gmail.com>, <matthew@kerwin.net.au>, <pmcmanus@mozilla.com>
- CC: <mnot@mnot.net>, <C.Brunhuber@iaea.org>, <ietf-http-wg@w3.org>
I'm sorry to respond to my own e-mail (below), but I don't understand why everybody is ignoring the security aspects of transfer/framing layer compression without contextual information (e.g. by intermediaries). Patrick brought it up yesterday, so obviously he still thinks its an issue. > On Apr 20, 2014 8:17 AM, "Patrick McManus" <pmcmanus@mozilla.com> wrote: > ... The alternative seems to be some form of per frame gzip changes at this point with no implementation > experience and a literal trail of tears in recent non-content-aware compression schemes when mixed with TLS. Regarding my suggestion below, will somebody please at least respond and tell me why I'm wrong and/or give another suggestion? On 19 April 2014 21:54, MORGAN, Keith Shearl wrote: > I suggest something like the following... > > Intermediaries MUST NOT add GZIP compression to a DATA frame. Intermediaries MAY > remove GZIP compression frome DATA frames if necessary. Intermediaries MAY also > remove and re-apply GZIP compression, so long as all compressed data were > originally compressed by the origin. > > For example, an intermediary might elect to remove GZIP compression for local > storage in its cache in order to more easily extract a range from the content. In > this case, when serving a range, the intermediary can choose to send the range in > DATA frames with no compression or with GZIP compression (or a combination > thereof). 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 Monday, 21 April 2014 12:23:17 UTC