Changeset 1406 for draft-ietf-httpbis/latest/p3-payload.html
- Timestamp:
- 24/08/11 01:30:58 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
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>
Note: See TracChangeset
for help on using the changeset viewer.