W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: Transfer-codings, mandatory content-coding support and intermediaries

From: <K.Morgan@iaea.org>
Date: Sat, 19 Apr 2014 19:54:44 +0000
To: <martin.thomson@gmail.com>, <matthew@kerwin.net.au>
CC: <mnot@mnot.net>, <C.Brunhuber@iaea.org>, <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC2011293EA20@sem001pd.sg.iaea.org>
Several of you (e.g. Martin [1]) have repeatedly mentioned security concerns w.r.t. "blanket" compression at the transfer layer without proper context about the data being compressed.

Have you all really changed your minds regarding the security implications? (If so, please share what convinced you otherwise.)

If not, I suggest adding restrictions to Matthew's PR [2] about the use of gzip frame compression.

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).

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0166.html

[2] https://github.com/phluid61/http2-spec/compare/445-gzip

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 Saturday, 19 April 2014 19:55:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC