Ignore:
Timestamp:
Aug 23, 2011, 6:30:58 PM (8 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.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.