CONTENT-ENCODING: FIXED revised proposed wording

[OOPS.  My previous message was missing one very important sentence,
regarding when "identity" content-codings are implicitly allowed.  -Jeff]

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

This is a rewrite of Henrik's proposed solution, from
	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0038.html

I have tried to make it somewhat more precise (especially about
what it means for a response to be "acceptable" according to the
Accept-Encoding header).

Also, Henrik has already pointed out that Content-Encoding is
legal on requests, not just on responses, and so we need to
specify what happens in certain corner cases there, as well.

-Jeff

(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) Replace section 14.3 (Accept-Encoding) entirely with

    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" ":" 
				     1#( codings [ ";" "q" "=" qvalue ] )
	    codings          = ( content-codings | "*" )
    
    Examples of its use are:
    
	   Accept-Encoding: compress, gzip
	   Accept-Encoding:
	   Accept-Encoding: *
	   Accept-Encoding: compress;q=0.5, gzip;q=1.0
	   Accept-Encoding: gzip=1.0; identity=0.5; *;q=0
    
    A server tests whether a content-coding is acceptable, according
    to an Accept-Encoding field, using these rules:
	(1) If the content-coding is one of the content-codings listed
	in the Accept-Encoding field, then it is acceptable. (Note that,
	as defined in section 3.9, a qvalue of 0 means "not acceptable".)
	(2) The special "*" symbol in an Accept-Encoding field matches
	any available content-coding.
	(3) If multiple content-codings are acceptable, then the
	acceptable content-coding with the highest non-zero qvalue is
	preferred.  
	(4) The "identity" content-coding is always acceptable, unless
	specifically refused because the Accept-Encoding field includes
	"identity;q=0", or because the field includes "*;q=0" and does
	not explictly include the "identity" content-coding.  If the
	Accept-Encoding field-value is empty, then only the "identity"
	encoding is acceptable.

    If an Accept-Encoding field is present in a request, 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.

    If no Accept-Encoding field is present in a request, the server MAY
    assume that the client will accept any content coding.  In this
    case, if "identity" is one of the available content-codings, then
    the server SHOULD use the "identity" content-coding.

	Note: If the request does not include an Accept-Encoding field,
	and if the "identity" content-coding is unavailable, then
	preference should be given to content-codings commonly
	understood by HTTP/1.0 clients (i.e., "gzip" and "compress");
	some older clients improperly display messages sent with other
	content-encodings.  The server may also make this decision
	based on information about the particular user-agent or
	client.

(3) In section 14.12 (Content-Encoding), replace

   The Content-Encoding is a characteristic of the entity identified by
   the Request-URI. Typically, the entity-body is stored with this
   encoding and is only decoded before rendering or analogous usage.

with

   The content-coding is a characteristic of the entity identified by
   the Request-URI. Typically, the entity-body is stored with this
   encoding and is only decoded before rendering or analogous usage.
   However, a proxy MAY modify the content-coding if the new coding
   is known to be acceptable to the recipient, unless the "no-transform"
   Cache-control directive is present in the message.

   If the content-coding of an entity is not "identity", then the
   response MUST including a Content-Encoding entity-header (section
   14.12) that lists the non-identity content-coding(s) used.

   If the content-coding of an entity in a request message is
   not acceptable to the origin server, the server SHOULD respond
   with a status code of 415 (Unsupported Media Type).

(4) In section 14.9 (Cache-Control), add
                          | "no-transform"
to the BNF for cache-request-directive.

(5) In section 14.9.5 (No-Transform Directive), replace

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

with

   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.

[End of proposed changes]

Received on Tuesday, 22 July 1997 18:31:50 UTC