Re: ISSUE CONTENT-ENCODING: Proposed wording

At 09:00 PM 7/4/97 +0200, Koen Holtman wrote:

>I tried to make sense of your message, but I have no idea which
>changes in the text you are actually proposing.  Could you just post
>the changes?

Sorry if it was not clear - here are the raw changes. For a discussion,
please see the previous mail at

	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0038.html

These are the suggested changes regarding the problems in content-encoding
and accept-encoding as described in

        http://www.w3.org/Protocols/HTTP/Issues/#CONTENT-ENCODING

1) In section 3.5 (Content Codings), add this after the item for "deflate"

        identity        The default (identity) encoding; the use
                        of no transformation whatsoever.  This
                        content-coding is used only in the
                        Accept-encoding header, and SHOULD NOT
                        be used in Content-coding header.

2) Modify section 14.12 (Content-Encoding), by adding (to the end of the
section)

   See section 14.3 for more requirements concerning the use of
   Content-Encoding.

   When an HTTP/1.1 server or proxy sends a response with a
   Content-Encoding header, [[and that header specifies a content-coding
   other than "gzip" or "compress",]] and the corresponding request was
   either

   (1)	received from a client whose version is lower than HTTP/1.1, or
   (2)	received with a Via header indicating that it was forwarded
	by a proxy whose version is lower than HTTP/1.1, and the response
	does not already include an Expires header, then the sender
	SHOULD include an Expires header whose field-value is identical
	to the field-value of its Date header. (This prevents improper
	caching of encoded responses by HTTP/1.0 proxies.)

3) Modify section 13.5.2 (Non-modifiable Headers) to replace this:

   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:

     o  Content-Location
     o  ETag
     o  Expires
     o  Last-Modified

with this:

   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:

     o  Content-Location
     o  ETag
     o  Last-Modified

   A cache or non-caching proxy MUST NOT modify the following
   field in a response

     o  Expires

   but it MAY add it if not present; if so, it MUST be given
   a field-value identical to the field-value of the Date header
   in that response.

I.e., we allow a proxy to add Expires if it has the effect of
making a response non-cachable.

4) Change section 14.3 with this

   14.3 Accept-Encoding 

   The Accept-Encoding request-header field restricts the set of
   content-codings (defined in section 3.5) that are acceptable for
   the response.  

       Accept-Encoding  = "Accept-Encoding" ":" 
                                 #( codings )
        codings          = ( content-codings | "*" )

   An example of its use is

       Accept-Encoding: compress, gzip

   The content-coding(s) of a response MUST be indicated by a
   Content-Encoding response-header (section 14.12), unless the
   "identity" content-coding is the only one used.

   If no Accept-Encoding field is present in a request, the server
   MAY assume that the client will accept any content coding.
   [[However, if the available representations use content-codings
   including the "identity" content-coding, and the client does not
   specify an "Accept-Encoding" field, then the server SHOULD use the
   "identity" content-coding; if all available representations use a
   non-identity content-coding, then preference should be given to
   those content-coding(s) commonly understood by older user agents,
   or known to be understood by the particular user agent that
   initiated the request.]]

   If an Accept-Encoding header is present, and if the server cannot
   send a response which is acceptable according to the Accept-
   Encoding header, then the server SHOULD send an error response
   with the 406 (Not Acceptable) status code.

   The special content-coding "*", if present in the Accept-Encoding
   field, matches every content-coding not matched by any other
   content-coding present in the Accept-Encoding field.

   An empty Accept-Encoding value indicates that only the "identity"
   content-coding is acceptable.

The text between  '[[' and ']]' can be moved to a compatibility appendix,
which probably makes more sense.

Henrik



--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Sunday, 6 July 1997 18:45:17 UTC