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: Mon, 21 Apr 2014 19:47:35 +0000
To: <martin.thomson@gmail.com>
CC: <matthew@kerwin.net.au>, <pmcmanus@mozilla.com>, <mnot@mnot.net>, <C.Brunhuber@iaea.org>, <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC20112941302@sem001pd.sg.iaea.org>
On 21 April 2014 20:30 Martin Thomson wrote:
> In general, if compliance with the "MUST" cannot be detected, then there's no point in saying it.
> ...

Thanks for the clarification.

Re-reading RFC 2119 [1], it seems like SHOULD NOT might be appropriate in this circumstance.  But regardless, at a minimum the security considerations of compression without proper context should be explicitly enumerated.

>From RFC 2119 Section 7...
"Document authors should take the time to elaborate the security implications of not following
recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification."

> Intermediaries SHOULD 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://tools.ietf.org/html/rfc2119

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 19:48:22 UTC

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