Changeset 1406


Ignore:
Timestamp:
24/08/11 01:30:58 (11 years ago)
Author:
fielding@…
Message:

Remove the "identity" content-coding -- it is just a token used
as a synonym for no encoding and calling it anything else makes
all the other requirements a silly mess.

Fix the English grammatical errors in recent changes to the
Accept* header fields.

Location:
draft-ietf-httpbis/latest
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r1405 r1406  
    9797chunk-ext-val = token / quoted-str-nf
    9898chunk-size = 1*HEXDIG
    99 codings = ( content-coding / "*" )
     99codings = content-coding / "identity" / "*"
    100100comment = "(" *( ctext / quoted-cpair / comment ) ")"
    101101connection-token = token

  • draft-ietf-httpbis/latest/p3-payload.html

    r1405 r1406  
    732732         </li>
    733733      </ul>
    734       <p id="rfc.section.2.2.p.7">identity<span id="rfc.iref.i.1"></span><span id="rfc.iref.c.6"></span> 
    735       </p>
    736       <ul class="empty">
    737          <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
    738             header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.
    739          </li>
    740       </ul>
    741734      <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h3>
    742735      <p id="rfc.section.2.2.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p>
    … …  
    10611054         quality".
    10621055      </p>
    1063       <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    1064          is present in a request, but the server cannot send a response which is acceptable, then the server can either send a response
    1065          in another format, or a 406 (Not Acceptable) response.
     1056      <p id="rfc.section.6.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept
     1057         header field is present in a request and none of the available representations for the response have a media type that is
     1058         listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating
     1059         the response as if it is not subject to content negotiation.
    10661060      </p>
    10671061      <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
    … …  
    11441138         mentioned get a quality value of 0.
    11451139      </p>
    1146       <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character encoding is acceptable. If an Accept-Charset
    1147          header field is present in a request, but the server cannot send a response which is acceptable, then the server can either
    1148          use another character encoding, or send a 406 (Not Acceptable) response.
     1140      <p id="rfc.section.6.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response.
     1141         If an Accept-Charset header field is present in a request and none of the available representations for the response have
     1142         a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header
     1143         field by treating the response as if it is not subject to content negotiation.
    11491144      </p>
    11501145      <div id="rfc.iref.a.3"></div>
    11511146      <div id="rfc.iref.h.3"></div>
    11521147      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1153       <p id="rfc.section.6.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
     1148      <p id="rfc.section.6.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when
     1149         no encoding is preferred.
    11541150      </p>
    11551151      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    1156   <a href="#header.accept-encoding" class="smpl">codings</a>          = ( <a href="#content.codings" class="smpl">content-coding</a> / "*" )
     1152  <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a>
     1153                                  / "identity"
     1154                                  / "*"
    11571155</pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
    11581156      </p>
    1159       <p id="rfc.section.6.3.p.4">Examples of its use are:</p>
     1157      <p id="rfc.section.6.3.p.4">For example,</p>
    11601158      <div id="rfc.figure.u.18"></div><pre class="text">  Accept-Encoding: compress, gzip
    11611159  Accept-Encoding:
    … …  
    11631161  Accept-Encoding: compress;q=0.5, gzip;q=1.0
    11641162  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
    1165 </pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
     1163</pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using
     1164         these rules:
     1165      </p>
    11661166      <ol>
    1167          <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1168             is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    1169          </li>
    11701167         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
    11711168            field.
    11721169         </li>
     1170         <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding
     1171            field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".
     1172         </li>
     1173         <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable
     1174            unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
     1175         </li>
    11731176         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
    1174          <li>The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes
    1175             "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the
    1176             Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
    1177          </li>
    11781177      </ol>
    1179       <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, but the server cannot send a response which is acceptable, then the server <em class="bcp14">SHOULD</em> send a response without any encoding (i.e., the "identity" encoding).
    1180       </p>
    1181       <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
    1182          then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the
    1183          client.
     1178      <p id="rfc.section.6.3.p.7">An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding
     1179         in response. If an Accept-Encoding header field is present in a request and none of the available representations for the
     1180         response have a content-coding that is listed as acceptable, the origin server <em class="bcp14">SHOULD</em> send a response without any content-coding.
     1181      </p>
     1182      <p id="rfc.section.6.3.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response,
     1183         but a representation without content-coding is preferred for compatibility with the widest variety of user agents.
    11841184      </p>
    11851185      <div class="note" id="rfc.section.6.3.p.9">
    1186          <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    1187             commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    1188             messages sent with other content-codings. The server might also make this decision based on information about the particular
    1189             user-agent or client.
    1190          </p>
    1191       </div>
    1192       <div class="note" id="rfc.section.6.3.p.10">
    11931186         <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    11941187            not work and are not permitted with x-gzip or x-compress.
    … …  
    12301223         </p>
    12311224      </div>
    1232       <div id="rfc.iref.c.7"></div>
     1225      <div id="rfc.iref.c.6"></div>
    12331226      <div id="rfc.iref.h.5"></div>
    12341227      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1235       <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what
    1236          decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
    1237          is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
     1228      <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
     1229         in the media type, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type
     1230         header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
     1231         its underlying media type.
    12381232      </p>
    12391233      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    … …  
    12451239         directive is present in the message.
    12461240      </p>
    1247       <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the non-identity content-coding(s) used.
    1248       </p>
    1249       <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1241      <p id="rfc.section.6.5.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
     1242         not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding
     1243         would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
     1244         server might choose to publish the same payload data as multiple representations that differ only in whether the coding is
     1245         defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each
     1246         response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
     1247      </p>
     1248      <p id="rfc.section.6.5.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the content-coding(s) applied.
    12501249      </p>
    12511250      <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    12521251      </p>
    1253       <div id="rfc.iref.c.8"></div>
     1252      <p id="rfc.section.6.5.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1253      </p>
     1254      <div id="rfc.iref.c.7"></div>
    12541255      <div id="rfc.iref.h.6"></div>
    12551256      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    … …  
    12771278      <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
    12781279      </p>
    1279       <div id="rfc.iref.c.9"></div>
     1280      <div id="rfc.iref.c.8"></div>
    12801281      <div id="rfc.iref.h.7"></div>
    12811282      <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    … …  
    13191320      </p>
    13201321      <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
    1321       <div id="rfc.iref.c.10"></div>
     1322      <div id="rfc.iref.c.9"></div>
    13221323      <div id="rfc.iref.h.8"></div>
    13231324      <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    … …  
    20352036      <p id="rfc.section.E.18.p.1">None yet.</p>
    20362037      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    2037       <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a>
     2038      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a>
    20382039      </p>
    20392040      <div class="print2col">
    … …  
    20562057                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.4">2.2</a></li>
    20572058                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.5">2.2</a></li>
    2058                         <li>identity&nbsp;&nbsp;<a href="#rfc.iref.c.6">2.2</a></li>
    20592059                     </ul>
    20602060                  </li>
    20612061                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.2">2.2</a></li>
    20622062                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1.1</a></li>
    2063                   <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">2.2</a>, <a href="#rfc.xref.header.content-encoding.2">4.1</a>, <a href="#rfc.iref.c.7"><b>6.5</b></a>, <a href="#rfc.xref.header.content-encoding.3">6.5</a>, <a href="#rfc.xref.header.content-encoding.4">7.1</a></li>
    2064                   <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">4.1</a>, <a href="#rfc.iref.c.8"><b>6.6</b></a>, <a href="#rfc.xref.header.content-language.2">7.1</a></li>
    2065                   <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">4.1</a>, <a href="#rfc.iref.c.9"><b>6.7</b></a>, <a href="#rfc.xref.header.content-location.2">7.1</a>, <a href="#rfc.xref.header.content-location.3">C</a></li>
    2066                   <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">2.3</a>, <a href="#rfc.xref.header.content-type.2">4.1</a>, <a href="#rfc.iref.c.10"><b>6.8</b></a>, <a href="#rfc.xref.header.content-type.3">7.1</a></li>
     2063                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">2.2</a>, <a href="#rfc.xref.header.content-encoding.2">4.1</a>, <a href="#rfc.iref.c.6"><b>6.5</b></a>, <a href="#rfc.xref.header.content-encoding.3">6.5</a>, <a href="#rfc.xref.header.content-encoding.4">7.1</a></li>
     2064                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">4.1</a>, <a href="#rfc.iref.c.7"><b>6.6</b></a>, <a href="#rfc.xref.header.content-language.2">7.1</a></li>
     2065                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">4.1</a>, <a href="#rfc.iref.c.8"><b>6.7</b></a>, <a href="#rfc.xref.header.content-location.2">7.1</a>, <a href="#rfc.xref.header.content-location.3">C</a></li>
     2066                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">2.3</a>, <a href="#rfc.xref.header.content-type.2">4.1</a>, <a href="#rfc.iref.c.9"><b>6.8</b></a>, <a href="#rfc.xref.header.content-type.3">7.1</a></li>
    20672067               </ul>
    20682068            </li>
    … …  
    21162116                     </ul>
    21172117                  </li>
    2118                </ul>
    2119             </li>
    2120             <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    2121                   <li>identity (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.i.1">2.2</a></li>
    21222118               </ul>
    21232119            </li>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1401 r1406  
    422422  </list>
    423423</t>
    424 <t>
    425    identity<iref item="identity (Coding Format)"/><iref item="Coding Format" subitem="identity"/>
    426   <list><t>
    427         The default (identity) encoding; the use of no transformation
    428         whatsoever. This content-coding is used only in the Accept-Encoding
    429         header field, and &SHOULD-NOT;  be used in the Content-Encoding
    430         header field.
    431   </t></list>
    432 </t>
    433424
    434425<section title="Content Coding Registry" anchor="content.coding.registry">
    … …  
    986977</t>
    987978<t>
    988    If no Accept header field is present, then it is assumed that the
    989    client accepts all media types. If an Accept header field is present in a
    990    request, but the server cannot send a response which is acceptable, then
    991    the server can either send a response in another format, or a 406 (Not
    992    Acceptable) response.
     979   A request without any Accept header field implies that the user agent
     980   will accept any media type in response.
     981   If an Accept header field is present in a request and none of the
     982   available representations for the response have a media type that is
     983   listed as acceptable, the origin server &MAY; either
     984   honor the Accept header field by sending a 406 (Not Acceptable) response
     985   or disregard the Accept header field by treating the response as if
     986   it is not subject to content negotiation.
    993987</t>
    994988<t>
    … …  
    10831077</t>
    10841078<t>
    1085    If no Accept-Charset header field is present, the default is that any
    1086    character encoding is acceptable. If an Accept-Charset header field is
    1087    present in a request, but the server cannot send a response which is
    1088    acceptable, then the server can either use another character encoding, or
    1089    send a 406 (Not Acceptable) response.
     1079   A request without any Accept-Charset header field implies that the user
     1080   agent will accept any character encoding in response.
     1081   If an Accept-Charset header field is present in a request and none of the
     1082   available representations for the response have a character encoding that
     1083   is listed as acceptable, the origin server &MAY; either honor the
     1084   Accept-Charset header field by sending a 406 (Not Acceptable) response or
     1085   disregard the Accept-Charset header field by treating the response as if
     1086   it is not subject to content negotiation.
    10901087</t>
    10911088</section>
    … …  
    10991096   The "Accept-Encoding" header field can be used by user agents to
    11001097   indicate what response content-codings (<xref target="content.codings"/>)
    1101    are acceptable in the response.
     1098   are acceptable in the response.  An "identity" token is used as a synonym
     1099   for "no encoding" in order to communicate when no encoding is preferred.
    11021100</t>
    11031101<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
    11041102  <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
    1105   <x:ref>codings</x:ref>          = ( <x:ref>content-coding</x:ref> / "*" )
     1103  <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref>
     1104                                  / "identity"
     1105                                  / "*"
    11061106</artwork></figure>
    11071107<t>
    … …  
    11101110</t>
    11111111<t>
    1112    Examples of its use are:
     1112   For example,
    11131113</t>
    11141114<figure><artwork type="example">
    … …  
    11201120</artwork></figure>
    11211121<t>
    1122    A server tests whether a content-coding is acceptable, according to
    1123    an Accept-Encoding field, using these rules:
     1122   A server tests whether a content-coding for a given representation is
     1123   acceptable, according to an Accept-Encoding field, using these rules:
    11241124  <list style="numbers">
    1125       <t>If the content-coding is one of the content-codings listed in
    1126          the Accept-Encoding field, then it is acceptable, unless it is
    1127          accompanied by a qvalue of 0. (As defined in &qvalue;, a
    1128          qvalue of 0 means "not acceptable".)</t>
    1129 
    11301125      <t>The special "*" symbol in an Accept-Encoding field matches any
    11311126         available content-coding not explicitly listed in the header
    11321127         field.</t>
    11331128
     1129      <t>If the representation has no content-coding, then it is acceptable
     1130         by default unless specifically excluded by the Accept-Encoding field
     1131         stating either "identity;q=0" or "*;q=0" without a more specific
     1132         entry for "identity".</t>
     1133
     1134      <t>If the representation's content-coding is one of the content-codings
     1135         listed in the Accept-Encoding field, then it is acceptable unless
     1136         it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
     1137         qvalue of 0 means "not acceptable".)</t>
     1138
    11341139      <t>If multiple content-codings are acceptable, then the acceptable
    11351140         content-coding with the highest non-zero qvalue is preferred.</t>
    1136 
    1137       <t>The "identity" content-coding is always acceptable, unless
    1138          specifically refused because the Accept-Encoding field includes
    1139          "identity;q=0", or because the field includes "*;q=0" and does
    1140          not explicitly include the "identity" content-coding. If the
    1141          Accept-Encoding field-value is empty, then only the "identity"
    1142          encoding is acceptable.</t>
    11431141  </list>
    11441142</t>
    11451143<t>
    1146    If an Accept-Encoding field is present in a request, but the server cannot
    1147    send a response which is acceptable, then the server &SHOULD; send a
    1148    response without any encoding (i.e., the "identity" encoding).
    1149 </t>
    1150 <t>
    1151    If no Accept-Encoding field is present in a request, the server &MAY;
    1152    assume that the client will accept any content coding. In this case,
    1153    if "identity" is one of the available content-codings, then the
    1154    server &SHOULD; use the "identity" content-coding, unless it has
    1155    additional information that a different content-coding is meaningful
    1156    to the client.
    1157 </t>
    1158 <x:note>
    1159   <t>
    1160     <x:h>Note:</x:h> If the request does not include an Accept-Encoding field,
    1161     and if the "identity" content-coding is unavailable, then
    1162     content-codings commonly understood by HTTP/1.0 clients (i.e.,
    1163     "gzip" and "compress") are preferred; some older clients
    1164     improperly display messages sent with other content-codings.  The
    1165     server might also make this decision based on information about
    1166     the particular user-agent or client.
    1167   </t>
    1168 </x:note>
     1144   An Accept-Encoding header field with a combined field-value that is empty
     1145   implies that the user agent does not want any content-coding in response.
     1146   If an Accept-Encoding header field is present in a request and none of the
     1147   available representations for the response have a content-coding that
     1148   is listed as acceptable, the origin server &SHOULD; send a response
     1149   without any content-coding.
     1150</t>
     1151<t>
     1152   A request without an Accept-Encoding header field implies that the user
     1153   agent will accept any content-coding in response, but a representation
     1154   without content-coding is preferred for compatibility with the widest
     1155   variety of user agents.
     1156</t>
    11691157<x:note>
    11701158  <t>
    … …  
    12511239<t>
    12521240   The "Content-Encoding" header field indicates what content-codings
    1253    have been applied to the representation, and thus what decoding mechanisms
    1254    must be applied in order to obtain the media-type referenced by the
    1255    Content-Type header field. Content-Encoding is primarily used to allow a
    1256    representation to be compressed without losing the identity of its underlying
    1257    media type.
     1241   have been applied to the representation beyond those inherent in the media
     1242   type, and thus what decoding mechanisms must be applied in order to obtain
     1243   the media-type referenced by the Content-Type header field.
     1244   Content-Encoding is primarily used to allow a representation to be
     1245   compressed without losing the identity of its underlying media type.
    12581246</t>
    12591247<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
    … …  
    12751263</t>
    12761264<t>
    1277    If the content-coding of a representation is not "identity", then the
    1278    representation metadata &MUST; include a Content-Encoding header
    1279    field (<xref target="header.content-encoding"/>)
    1280    that lists the non-identity content-coding(s) used.
    1281 </t>
    1282 <t>
    1283    If the content-coding of a representation in a request message is not
    1284    acceptable to the origin server, the server &SHOULD; respond with a
    1285    status code of 415 (Unsupported Media Type).
     1265   If the media type includes an inherent encoding, such as a data format
     1266   that is always compressed, then that encoding would not be restated as
     1267   a Content-Encoding even if it happens to be the same algorithm as one
     1268   of the content-codings.  Such a content-coding would only be listed if,
     1269   for some bizarre reason, it is applied a second time to form the
     1270   representation.  Likewise, an origin server might choose to publish the
     1271   same payload data as multiple representations that differ only in whether
     1272   the coding is defined as part of Content-Type or Content-Encoding, since
     1273   some user agents will behave differently in their handling of each
     1274   response (e.g., open a "Save as ..." dialog instead of automatic
     1275   decompression and rendering of content).
     1276</t>
     1277<t>
     1278   A representation that has a content-coding applied to it &MUST; include
     1279   a Content-Encoding header field (<xref target="header.content-encoding"/>)
     1280   that lists the content-coding(s) applied.
    12861281</t>
    12871282<t>
    … …  
    12901285   Additional information about the encoding parameters &MAY; be provided
    12911286   by other header fields not defined by this specification.
     1287</t>
     1288<t>
     1289   If the content-coding of a representation in a request message is not
     1290   acceptable to the origin server, the server &SHOULD; respond with a
     1291   status code of 415 (Unsupported Media Type).
    12921292</t>
    12931293</section>
    … …  
    15611561      &gzip-coding;
    15621562   </c>
    1563    <c>identity</c>
    1564    <c>No transformation</c>
    1565    <c>
    1566       <xref target="content.codings"/>
    1567    </c>
    15681563</texttable>
    15691564</section>
Note: See TracChangeset for help on using the changeset viewer.