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

Updated proposal for CONTENT-ENCODING issue

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 24 Jul 97 19:08:22 MDT
Message-Id: <9707250208.AA17285@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
[incorporates the edits I made in response to Koen's comments.]

(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, unless it
	is accompanied by a qvalue of 0.  (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 not explicitly listed in the header
        field.
	(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, unless
    it has additional information that a different content-coding
    is meaningful to the client.

	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 Thursday, 24 July 1997 19:17:30 EDT

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