Changeset 1406
- Timestamp:
- 24/08/11 01:30:58 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/httpbis.abnf
r1405 r1406 97 97 chunk-ext-val = token / quoted-str-nf 98 98 chunk-size = 1*HEXDIG 99 codings = ( content-coding / "*" )99 codings = content-coding / "identity" / "*" 100 100 comment = "(" *( ctext / quoted-cpair / comment ) ")" 101 101 connection-token = token -
draft-ietf-httpbis/latest/p3-payload.html
r1405 r1406 732 732 </li> 733 733 </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-Encoding738 header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.739 </li>740 </ul>741 734 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h3> 742 735 <p id="rfc.section.2.2.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p> … … 1061 1054 quality". 1062 1055 </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. 1066 1060 </p> 1067 1061 <p id="rfc.section.6.1.p.10">A more elaborate example is</p> … … 1144 1138 mentioned get a quality value of 0. 1145 1139 </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. 1149 1144 </p> 1150 1145 <div id="rfc.iref.a.3"></div> 1151 1146 <div id="rfc.iref.h.3"></div> 1152 1147 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <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 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 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. 1154 1150 </p> 1155 1151 <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 / "*" 1157 1155 </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. 1158 1156 </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> 1160 1158 <div id="rfc.figure.u.18"></div><pre class="text"> Accept-Encoding: compress, gzip 1161 1159 Accept-Encoding: … … 1163 1161 Accept-Encoding: compress;q=0.5, gzip;q=1.0 1164 1162 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> 1166 1166 <ol> 1167 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it1168 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>1170 1167 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 1171 1168 field. 1172 1169 </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> 1173 1176 <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 includes1175 "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the1176 Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.1177 </li>1178 1177 </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. 1184 1184 </p> 1185 1185 <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-codings1187 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display1188 messages sent with other content-codings. The server might also make this decision based on information about the particular1189 user-agent or client.1190 </p>1191 </div>1192 <div class="note" id="rfc.section.6.3.p.10">1193 1186 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 1194 1187 not work and are not permitted with x-gzip or x-compress. … … 1230 1223 </p> 1231 1224 </div> 1232 <div id="rfc.iref.c. 7"></div>1225 <div id="rfc.iref.c.6"></div> 1233 1226 <div id="rfc.iref.h.5"></div> 1234 1227 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <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. 1238 1232 </p> 1239 1233 <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> … … 1245 1239 directive is present in the message. 1246 1240 </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 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 6.5</a>) that lists the content-coding(s) applied. 1250 1249 </p> 1251 1250 <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. 1252 1251 </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> 1254 1255 <div id="rfc.iref.h.6"></div> 1255 1256 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> … … 1277 1278 <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. 1278 1279 </p> 1279 <div id="rfc.iref.c. 9"></div>1280 <div id="rfc.iref.c.8"></div> 1280 1281 <div id="rfc.iref.h.7"></div> 1281 1282 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> … … 1319 1320 </p> 1320 1321 <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> 1322 1323 <div id="rfc.iref.h.8"></div> 1323 1324 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> … … 2035 2036 <p id="rfc.section.E.18.p.1">None yet.</p> 2036 2037 <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> 2038 2039 </p> 2039 2040 <div class="print2col"> … … 2056 2057 <li>deflate <a href="#rfc.iref.c.4">2.2</a></li> 2057 2058 <li>gzip <a href="#rfc.iref.c.5">2.2</a></li> 2058 <li>identity <a href="#rfc.iref.c.6">2.2</a></li>2059 2059 </ul> 2060 2060 </li> 2061 2061 <li>compress (Coding Format) <a href="#rfc.iref.c.2">2.2</a></li> 2062 2062 <li>content negotiation <a href="#rfc.iref.c.1">1.1</a></li> 2063 <li>Content-Encoding header field <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 <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 <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 <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 <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 <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 <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 <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> 2067 2067 </ul> 2068 2068 </li> … … 2116 2116 </ul> 2117 2117 </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) <a href="#rfc.iref.i.1">2.2</a></li>2122 2118 </ul> 2123 2119 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r1401 r1406 422 422 </list> 423 423 </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 transformation428 whatsoever. This content-coding is used only in the Accept-Encoding429 header field, and &SHOULD-NOT; be used in the Content-Encoding430 header field.431 </t></list>432 </t>433 424 434 425 <section title="Content Coding Registry" anchor="content.coding.registry"> … … 986 977 </t> 987 978 <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. 993 987 </t> 994 988 <t> … … 1083 1077 </t> 1084 1078 <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. 1090 1087 </t> 1091 1088 </section> … … 1099 1096 The "Accept-Encoding" header field can be used by user agents to 1100 1097 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. 1102 1100 </t> 1103 1101 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/> 1104 1102 <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 / "*" 1106 1106 </artwork></figure> 1107 1107 <t> … … 1110 1110 </t> 1111 1111 <t> 1112 Examples of its use are:1112 For example, 1113 1113 </t> 1114 1114 <figure><artwork type="example"> … … 1120 1120 </artwork></figure> 1121 1121 <t> 1122 A server tests whether a content-coding is acceptable, according to1123 a n 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: 1124 1124 <list style="numbers"> 1125 <t>If the content-coding is one of the content-codings listed in1126 the Accept-Encoding field, then it is acceptable, unless it is1127 accompanied by a qvalue of 0. (As defined in &qvalue;, a1128 qvalue of 0 means "not acceptable".)</t>1129 1130 1125 <t>The special "*" symbol in an Accept-Encoding field matches any 1131 1126 available content-coding not explicitly listed in the header 1132 1127 field.</t> 1133 1128 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 1134 1139 <t>If multiple content-codings are acceptable, then the acceptable 1135 1140 content-coding with the highest non-zero qvalue is preferred.</t> 1136 1137 <t>The "identity" content-coding is always acceptable, unless1138 specifically refused because the Accept-Encoding field includes1139 "identity;q=0", or because the field includes "*;q=0" and does1140 not explicitly include the "identity" content-coding. If the1141 Accept-Encoding field-value is empty, then only the "identity"1142 encoding is acceptable.</t>1143 1141 </list> 1144 1142 </t> 1145 1143 <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> 1169 1157 <x:note> 1170 1158 <t> … … 1251 1239 <t> 1252 1240 The "Content-Encoding" header field indicates what content-codings 1253 have been applied to the representation , and thus what decoding mechanisms1254 must be applied in order to obtain the media-type referenced by the1255 Content-Type header field. Content-Encoding is primarily used to allow a1256 representation to be compressed without losing the identity of its underlying1257 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. 1258 1246 </t> 1259 1247 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/> … … 1275 1263 </t> 1276 1264 <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. 1286 1281 </t> 1287 1282 <t> … … 1290 1285 Additional information about the encoding parameters &MAY; be provided 1291 1286 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). 1292 1292 </t> 1293 1293 </section> … … 1561 1561 &gzip-coding; 1562 1562 </c> 1563 <c>identity</c>1564 <c>No transformation</c>1565 <c>1566 <xref target="content.codings"/>1567 </c>1568 1563 </texttable> 1569 1564 </section>
Note: See TracChangeset
for help on using the changeset viewer.