Subject: WGLC issue: 'no-transform'

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Nov 2012 16:58:46 +1100

p1 says:

> A proxy must not modify or add any of the following fields in a message that contains the no-transform cache-control directive:
> 
> 	• Content-Encoding (Section 3.1.2.2 of [Part2])
> 	• Content-Range (Section 5.2 of [Part5])
> 	• Content-Type (Section 3.1.1.5 of [Part2])
> A transforming proxy may modify or add these fields to a message that does not include no-transform, but if it does so, it must add a Warning 214 (Transformation applied) if one does not already appear in the message (see Section 7.5 of [Part6]).

p6 says: 

> 7.2.2.9 no-transform
> 
> The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) must not change the Content-Encoding, Content-Range orContent-Type response header fields, nor the response representation.

2616 was a bit more wordy:

> 14.9.5 No-Transform Directive
> 
>    no-transform
>       Implementors of intermediate caches (proxies) have found it useful
>       to convert the media type of certain entity bodies. A non-
>       transparent proxy might, for example, convert between image
>       formats in order to save cache space or to reduce the amount of
>       traffic on a slow link.
> 
>       Serious operational problems occur, however, when these
>       transformations are applied to entity bodies intended for certain
>       kinds of applications. For example, applications for medical
>       imaging, scientific data analysis and those using end-to-end
>       authentication, all depend on receiving an entity body that is bit
>       for bit identical to the original entity-body.
> 
>       Therefore, if a message includes the no-transform directive, an
>       intermediate cache or proxy MUST NOT change those headers that are
>       listed in section 13.5.2 as being subject to the no-transform
>       directive. This implies that the cache or proxy MUST NOT change
>       any aspect of the entity-body that is specified by these headers,
>       including the value of the entity-body itself.

(the text currently in p1 closely corresponds to that in 2616's 13.5.2).

The issue here is that the intent in 2616 is clear -- the body shouldn't be modified if no-transform is present -- but since we split it up, a reader of p1 doesn't have any indication of this unless they chase up in p6 (note there isn't any reference, beyond the unrelated one to the Warning header).

I'd suggest we need p1 to explicitly say the body can't be changed, as p6 does.

While we're at it, changing "A proxy must not modify or add any of the following fields..." to "A proxy (transparent or non-transparent) must not modify or add any of the following fields " would make what's going on a lot clearer.

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Nov 2012 08:15:06 +0100

On Mon, Nov 26, 2012 at 04:58:46PM +1100, Mark Nottingham wrote:
> > 	? Content-Encoding (Section 3.1.2.2 of [Part2])
> > 	? Content-Range (Section 5.2 of [Part5])
> > 	? Content-Type (Section 3.1.1.5 of [Part2])

I agree. Also, I think we should take the intent from 2616 which clearly
explains *why* proxies must absolutely respect this rule. I have already
seen some proxies recompress whatever they could without any consideration
for the importance of original data, so having this would be really nice.

> While we're at it, changing "A proxy must not modify or add any of the following fields..." to "A proxy (transparent or non-transparent) must not modify or add any of the following fields " would m…

+1 for me too.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Nov 2012 13:37:20 +1100

... now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/418>.