W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

EDITs to 13.4.2, 14.9.5, and 14.45 (related to no-transform)

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 06 Jun 96 14:32:29 MDT
Message-Id: <9606062132.AA19719@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: jg@w3.org
These edits reflect my understanding and recollection of the consenus
developed during today's editorial teleconference.  Anyone who wishes
to comment on them should do so immediately, since the deadline for
the next I-D submission is less than 24 hours from now.

The intention of these changes is to make the specification of
no-transform more precise, and to prevent undetected loss of
information when (possibly lossy) transforms are applied.

13.4.2 Non-modifiable Headers

Current (draft-04) wording:

    A cache or non-caching proxy MUST NOT modify any of the following fields
    in a request or response, nor may it add any of these fields if not
    already present:
      .  Content-Encoding
      .  Content-Length
      .  Content-Location
      .  Content-Range
      .  Content-Type
      .  Expires
      .  Last-Modified

New wording    

    A cache or non-caching proxy MUST NOT modify any of the following fields
    in a request or response, nor may it add any of these fields if not
    already present:
      .  Content-Location
      .  Expires
      .  Last-Modified

    A cache or non-caching proxy MUST NOT modify or add any of the
    following fields in a response that contains the no-transform
    Cache-Control directive, or in any request:
      .  Content-Encoding
      .  Content-Length
      .  Content-Range
      .  Content-Type
    A cache or non-caching proxy MAY modify or add these fields
    in a response that does not include no-transform, but if it
    does so, it MUST add a Warning 14 (Transformation applied)
    if one does not already appear in the response.

14.9.5 No-Transform Directive

New wording (mostly based on Jim Gettys' message of 06 Jun 96 12:50:43 EDT)
  Intermediate caches (proxies) have found it useful to convert the
  media type of certain entity bodies.  A 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.  HTTP has to date
  been silent on these transformations.

  Serious operational problems have already occured, however, when these
  transformations have been 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 require that the original entity-body be reproduced exactly bit for bit.
  Therefore, if a response includes the no-transform directive, an
  intermediate cache or proxy MUST NOT change those headers that
  are listed in section 13.4.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.

14.45 Warning

Change:
    Any server or cache may add Warning headers to a response. New Warning
    headers should be added after any existing Warning headers. A cache MUST
    NOT delete any Warning header that it received with a response. However,
    if a cache successfully validates a cache entry, it SHOULD remove any
    Warning headers previously attached to that entry. It MUST then add any
    Warning headers received in the validating response. In other words,
    Warning headers are those that would be attached to the most recent
    relevant response.

To
    Any server or cache may add Warning headers to a response. New Warning
    headers should be added after any existing Warning headers. A cache MUST
    NOT delete any Warning header that it received with a response. However,
    if a cache successfully validates a cache entry, it SHOULD remove any
    Warning headers previously attached to that entry
+   except as specified for specific Warning codes.
    It MUST then add any
    Warning headers received in the validating response. In other words,
    Warning headers are those that would be attached to the most recent
    relevant response.

Add to the list of Warning codes (between 13 and 99)

    14 Transformation applied
	MUST be added by an intermediate cache or proxy if it applies
	any transformation changing the content-coding (as specified in
	the Content-Encoding header) or media-type (as specified in the
	Content-Type header) of the response, unless this Warning
	code already appears in the response.  MUST NOT be deleted
	from a response even after revalidation.

	
-Jeff
Received on Thursday, 6 June 1996 14:48:04 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:03 EDT