Changeset 1633
- Timestamp:
- 28/03/12 17:34:31 (10 years ago)
- Location:
- draft-ietf-httpbis/experiment
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/experiment/p2-semantics.html
r1631 r1633 723 723 </li> 724 724 <li>9. <a href="#header.field.definitions">Header Field Definitions</a><ul> 725 <li>9.1 <a href="#header.a llow">Allow</a></li>726 <li>9.2 <a href="#header. date">Date</a></li>727 <li>9.3 <a href="#header. expect">Expect</a></li>728 <li>9.4 <a href="#header. from">From</a></li>729 <li>9.5 <a href="#header. location">Location</a></li>730 <li>9.6 <a href="#header. max-forwards">Max-Forwards</a></li>731 <li>9.7 <a href="#header. referer">Referer</a></li>732 <li>9.8 <a href="#header. retry-after">Retry-After</a></li>733 <li>9.9 <a href="#header. server">Server</a></li>734 <li>9.10 <a href="#header. user-agent">User-Agent</a></li>735 <li>9.11 <a href="#header. accept">Accept</a></li>736 <li>9.12 <a href="#header. accept-charset">Accept-Charset</a></li>737 <li>9.13 <a href="#header. accept-encoding">Accept-Encoding</a></li>738 <li>9.14 <a href="#header. accept-language">Accept-Language</a></li>739 <li>9.15 <a href="#header. content-encoding">Content-Encoding</a></li>740 <li>9.16 <a href="#header. content-language">Content-Language</a></li>741 <li>9.17 <a href="#header. content-location">Content-Location</a></li>742 <li>9.18 <a href="#header. content-type">Content-Type</a></li>725 <li>9.1 <a href="#header.accept">Accept</a></li> 726 <li>9.2 <a href="#header.accept-charset">Accept-Charset</a></li> 727 <li>9.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 728 <li>9.4 <a href="#header.accept-language">Accept-Language</a></li> 729 <li>9.5 <a href="#header.allow">Allow</a></li> 730 <li>9.6 <a href="#header.content-encoding">Content-Encoding</a></li> 731 <li>9.7 <a href="#header.content-language">Content-Language</a></li> 732 <li>9.8 <a href="#header.content-location">Content-Location</a></li> 733 <li>9.9 <a href="#header.content-type">Content-Type</a></li> 734 <li>9.10 <a href="#header.date">Date</a></li> 735 <li>9.11 <a href="#header.expect">Expect</a></li> 736 <li>9.12 <a href="#header.from">From</a></li> 737 <li>9.13 <a href="#header.location">Location</a></li> 738 <li>9.14 <a href="#header.max-forwards">Max-Forwards</a></li> 739 <li>9.15 <a href="#header.referer">Referer</a></li> 740 <li>9.16 <a href="#header.retry-after">Retry-After</a></li> 741 <li>9.17 <a href="#header.server">Server</a></li> 742 <li>9.18 <a href="#header.user-agent">User-Agent</a></li> 743 743 </ul> 744 744 </li> … … 903 903 </p> 904 904 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> 905 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9. 1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the905 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 906 906 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the 907 907 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET … … 983 983 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 984 984 </p> 985 <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9. 6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.985 <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 986 986 </p> 987 987 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="GET" href="#GET">GET</a></h3> … … 1041 1041 </p> 1042 1042 <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1043 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9. 5</a>).1044 </p> 1045 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 9. 17</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1043 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.13</a>). 1044 </p> 1045 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1046 1046 </p> 1047 1047 <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1131 1131 <div id="rfc.iref.m.7"></div> 1132 1132 <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 1133 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9. 6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.1133 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1134 1134 </p> 1135 1135 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 1206 1206 double quotes will likely cause unnecessary confusion. 1207 1207 </p> 1208 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 9. 18</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing1208 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 1209 1209 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 1210 1210 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section 5.5</a>). … … 1263 1263 <tr> 1264 1264 <td class="left">Accept</td> 1265 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 9.1 1</a></td>1265 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 9.1</a></td> 1266 1266 </tr> 1267 1267 <tr> 1268 1268 <td class="left">Accept-Charset</td> 1269 <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 9. 12</a></td>1269 <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 9.2</a></td> 1270 1270 </tr> 1271 1271 <tr> 1272 1272 <td class="left">Accept-Encoding</td> 1273 <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 9. 13</a></td>1273 <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 9.3</a></td> 1274 1274 </tr> 1275 1275 <tr> 1276 1276 <td class="left">Accept-Language</td> 1277 <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 9. 14</a></td>1277 <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 9.4</a></td> 1278 1278 </tr> 1279 1279 <tr> … … 1283 1283 <tr> 1284 1284 <td class="left">Expect</td> 1285 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9. 3</a></td>1285 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.11</a></td> 1286 1286 </tr> 1287 1287 <tr> 1288 1288 <td class="left">From</td> 1289 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9. 4</a></td>1289 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.12</a></td> 1290 1290 </tr> 1291 1291 <tr> … … 1315 1315 <tr> 1316 1316 <td class="left">Max-Forwards</td> 1317 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9. 6</a></td>1317 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9.14</a></td> 1318 1318 </tr> 1319 1319 <tr> … … 1327 1327 <tr> 1328 1328 <td class="left">Referer</td> 1329 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9. 7</a></td>1329 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.15</a></td> 1330 1330 </tr> 1331 1331 <tr> … … 1335 1335 <tr> 1336 1336 <td class="left">User-Agent</td> 1337 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.1 0</a></td>1337 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.18</a></td> 1338 1338 </tr> 1339 1339 </tbody> … … 1363 1363 <tr> 1364 1364 <td class="left">Allow</td> 1365 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 9. 1</a></td>1365 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 9.5</a></td> 1366 1366 </tr> 1367 1367 <tr> 1368 1368 <td class="left">Date</td> 1369 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 9. 2</a></td>1369 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 9.10</a></td> 1370 1370 </tr> 1371 1371 <tr> … … 1375 1375 <tr> 1376 1376 <td class="left">Location</td> 1377 <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9. 5</a></td>1377 <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.13</a></td> 1378 1378 </tr> 1379 1379 <tr> … … 1383 1383 <tr> 1384 1384 <td class="left">Retry-After</td> 1385 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9. 8</a></td>1385 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.16</a></td> 1386 1386 </tr> 1387 1387 <tr> 1388 1388 <td class="left">Server</td> 1389 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9. 9</a></td>1389 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.17</a></td> 1390 1390 </tr> 1391 1391 <tr> … … 1424 1424 </ul> 1425 1425 <p id="rfc.section.4.p.6">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's 1426 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 9. 18</a>).1426 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 9.9</a>). 1427 1427 </p> 1428 1428 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> … … 1820 1820 </p> 1821 1821 </div> 1822 <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9. 5</a>.1822 <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9.13</a>. 1823 1823 </p> 1824 1824 <p id="rfc.section.4.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was … … 2036 2036 <div id="rfc.iref.s.31"></div> 2037 2037 <h3 id="rfc.section.4.6.14"><a href="#rfc.section.4.6.14">4.6.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2038 <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9. 3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could2038 <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 2039 2039 not be met by the next-hop server. 2040 2040 </p> … … 2081 2081 <p id="rfc.section.4.7.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 2082 2082 <p id="rfc.section.4.7.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the 2083 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 9. 8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.2083 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2084 2084 </p> 2085 2085 <div class="note" id="rfc.section.4.7.4.p.3"> … … 2228 2228 </p> 2229 2229 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 2230 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 9. 13</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 9.15</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding2230 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 9.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 2231 2231 mechanism will be required to remove the encoding. 2232 2232 </p> … … 2265 2265 </p> 2266 2266 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="media.types" href="#media.types">Media Types</a></h2> 2267 <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 9. 18</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 9.11</a>) header fields in order to provide open and extensible data typing and type negotiation.2267 <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 9.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 9.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 2268 2268 </p> 2269 2269 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) … … 2436 2436 <tr> 2437 2437 <td class="left">Content-Encoding</td> 2438 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 9. 15</a></td>2438 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 9.6</a></td> 2439 2439 </tr> 2440 2440 <tr> 2441 2441 <td class="left">Content-Language</td> 2442 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 9. 16</a></td>2442 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 9.7</a></td> 2443 2443 </tr> 2444 2444 <tr> 2445 2445 <td class="left">Content-Location</td> 2446 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 9. 17</a></td>2446 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 9.8</a></td> 2447 2447 </tr> 2448 2448 <tr> 2449 2449 <td class="left">Content-Type</td> 2450 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 9. 18</a></td>2450 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 9.9</a></td> 2451 2451 </tr> 2452 2452 <tr> … … 2561 2561 </p> 2562 2562 <p id="rfc.section.8.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 2563 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 9.1 1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 9.12</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 9.13</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 9.14</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.10</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information2563 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 9.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 9.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 9.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 9.4</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 2564 2564 within extension header fields not defined by this specification. 2565 2565 </p> … … 2595 2595 <div id="rfc.iref.a.1"></div> 2596 2596 <div id="rfc.iref.h.2"></div> 2597 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2598 <p id="rfc.section.9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2597 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 2598 <p id="rfc.section.9.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields 2599 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 2600 for an in-line image. 2601 </p> 2602 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 2603 2604 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" 2605 / ( <a href="#media.types" class="smpl">type</a> "/" "*" ) 2606 / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> ) 2607 ) *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 2608 <a href="#header.accept" class="smpl">accept-params</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> *( <a href="#header.accept" class="smpl">accept-ext</a> ) 2609 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ] 2610 </pre><p id="rfc.section.9.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 2611 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 2612 </p> 2613 <p id="rfc.section.9.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 2614 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 2615 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (qvalue;). The 2616 default value is q=1. 2617 </p> 2618 <div class="note" id="rfc.section.9.1.p.5"> 2619 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 2620 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 2621 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 2622 in Accept. Future media types are discouraged from registering any parameter named "q". 2623 </p> 2624 </div> 2625 <p id="rfc.section.9.1.p.6">The example</p> 2626 <div id="rfc.figure.u.26"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 2627 </pre><p id="rfc.section.9.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 2628 quality". 2629 </p> 2630 <p id="rfc.section.9.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 2631 header field is present in a request and none of the available representations for the response have a media type that is 2632 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 2633 the response as if it is not subject to content negotiation. 2634 </p> 2635 <p id="rfc.section.9.1.p.10">A more elaborate example is</p> 2636 <div id="rfc.figure.u.27"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 2637 text/x-dvi; q=0.8, text/x-c 2638 </pre><p id="rfc.section.9.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 2639 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 2640 </p> 2641 <p id="rfc.section.9.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 2642 to a given type, the most specific reference has precedence. For example, 2643 </p> 2644 <div id="rfc.figure.u.28"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 2645 </pre><p id="rfc.section.9.1.p.15">have the following precedence: </p> 2646 <ol> 2647 <li>text/plain;format=flowed</li> 2648 <li>text/plain</li> 2649 <li>text/*</li> 2650 <li>*/*</li> 2651 </ol> 2652 <p id="rfc.section.9.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 2653 which matches that type. For example, 2654 </p> 2655 <div id="rfc.figure.u.29"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 2656 text/html;level=2;q=0.4, */*;q=0.5 2657 </pre><p id="rfc.section.9.1.p.18">would cause the following values to be associated:</p> 2658 <div id="rfc.table.u.7"> 2659 <table class="tt full left" cellpadding="3" cellspacing="0"> 2660 <thead> 2661 <tr> 2662 <th>Media Type</th> 2663 <th>Quality Value</th> 2664 </tr> 2665 </thead> 2666 <tbody> 2667 <tr> 2668 <td class="left">text/html;level=1</td> 2669 <td class="left">1</td> 2670 </tr> 2671 <tr> 2672 <td class="left">text/html</td> 2673 <td class="left">0.7</td> 2674 </tr> 2675 <tr> 2676 <td class="left">text/plain</td> 2677 <td class="left">0.3</td> 2678 </tr> 2679 <tr> 2680 <td class="left">image/jpeg</td> 2681 <td class="left">0.5</td> 2682 </tr> 2683 <tr> 2684 <td class="left">text/html;level=2</td> 2685 <td class="left">0.4</td> 2686 </tr> 2687 <tr> 2688 <td class="left">text/html;level=3</td> 2689 <td class="left">0.7</td> 2690 </tr> 2691 </tbody> 2692 </table> 2693 </div> 2694 <p id="rfc.section.9.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 2695 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 2696 </p> 2697 <div id="rfc.iref.a.2"></div> 2698 <div id="rfc.iref.h.3"></div> 2699 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 2700 <p id="rfc.section.9.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response 2701 payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal 2702 that capability to a server which is capable of representing documents in those character encodings. 2703 </p> 2704 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.38"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 2705 [ <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> ] ) 2706 </pre><p id="rfc.section.9.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 2707 example is 2708 </p> 2709 <div id="rfc.figure.u.31"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 2710 </pre><p id="rfc.section.9.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere 2711 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly 2712 mentioned get a quality value of 0. 2713 </p> 2714 <p id="rfc.section.9.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response. 2715 If an Accept-Charset header field is present in a request and none of the available representations for the response have 2716 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 2717 field by treating the response as if it is not subject to content negotiation. 2718 </p> 2719 <div id="rfc.iref.a.3"></div> 2720 <div id="rfc.iref.h.4"></div> 2721 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 2722 <p id="rfc.section.9.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 5.4</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when 2723 no encoding is preferred. 2724 </p> 2725 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></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> ] ) 2726 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 2727 </pre><p id="rfc.section.9.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. 2728 </p> 2729 <p id="rfc.section.9.3.p.4">For example,</p> 2730 <div id="rfc.figure.u.33"></div><pre class="text"> Accept-Encoding: compress, gzip 2731 Accept-Encoding: 2732 Accept-Encoding: * 2733 Accept-Encoding: compress;q=0.5, gzip;q=1.0 2734 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 2735 </pre><p id="rfc.section.9.3.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using 2736 these rules: 2737 </p> 2738 <ol> 2739 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 2740 field. 2741 </li> 2742 <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding 2743 field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". 2744 </li> 2745 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 2746 unless it is accompanied by a qvalue of 0. (As defined in qvalue;, a qvalue of 0 means "not acceptable".) 2747 </li> 2748 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 2749 </ol> 2750 <p id="rfc.section.9.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 2751 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 2752 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. 2753 </p> 2754 <p id="rfc.section.9.3.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response, 2755 but a representation without content-coding is preferred for compatibility with the widest variety of user agents. 2756 </p> 2757 <div class="note" id="rfc.section.9.3.p.9"> 2758 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 2759 not work and are not permitted with x-gzip or x-compress. 2760 </p> 2761 </div> 2762 <div id="rfc.iref.a.4"></div> 2763 <div id="rfc.iref.h.5"></div> 2764 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 2765 <p id="rfc.section.9.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred 2766 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 5.6</a>. 2767 </p> 2768 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 2769 1#( <a href="#header.accept-language" class="smpl">language-range</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> ] ) 2770 <a href="#header.accept-language" class="smpl">language-range</a> = 2771 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> 2772 </pre><p id="rfc.section.9.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the 2773 languages specified by that range. The quality value defaults to "q=1". For example, 2774 </p> 2775 <div id="rfc.figure.u.35"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 2776 </pre><p id="rfc.section.9.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 2777 </p> 2778 <p id="rfc.section.9.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. 2779 </p> 2780 <div class="note" id="rfc.section.9.4.p.7"> 2781 <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2782 </p> 2783 </div> 2784 <p id="rfc.section.9.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 2785 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section 11.5</a>. 2786 </p> 2787 <p id="rfc.section.9.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 2788 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 2789 </p> 2790 <div class="note" id="rfc.section.9.4.p.10"> 2791 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 2792 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, 2793 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 2794 A user agent might suggest in such a case to add "en" to get the best matching behavior. 2795 </p> 2796 </div> 2797 <div id="rfc.iref.a.5"></div> 2798 <div id="rfc.iref.h.6"></div> 2799 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2800 <p id="rfc.section.9.5.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2599 2801 is strictly to inform the recipient of valid request methods associated with the resource. 2600 2802 </p> 2601 <div id="rfc.figure.u. 25"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>2602 </pre><p id="rfc.section.9. 1.p.3">Example of use:</p>2603 <div id="rfc.figure.u. 26"></div><pre class="text"> Allow: GET, HEAD, PUT2604 </pre><p id="rfc.section.9. 1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>2605 <p id="rfc.section.9. 1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according2803 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a> 2804 </pre><p id="rfc.section.9.5.p.3">Example of use:</p> 2805 <div id="rfc.figure.u.37"></div><pre class="text"> Allow: GET, HEAD, PUT 2806 </pre><p id="rfc.section.9.5.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 2807 <p id="rfc.section.9.5.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according 2606 2808 to the generic message handling rules. 2607 2809 </p> 2810 <div id="rfc.iref.c.7"></div> 2811 <div id="rfc.iref.h.7"></div> 2812 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 2813 <p id="rfc.section.9.6.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 2814 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 2815 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 2816 identity of its underlying media type. 2817 </p> 2818 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 2819 </pre><p id="rfc.section.9.6.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 5.4</a>. An example of its use is 2820 </p> 2821 <div id="rfc.figure.u.39"></div><pre class="text"> Content-Encoding: gzip 2822 </pre><p id="rfc.section.9.6.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 2823 and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 2824 directive is present in the message. 2825 </p> 2826 <p id="rfc.section.9.6.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would 2827 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 2828 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin 2829 server might choose to publish the same payload data as multiple representations that differ only in whether the coding is 2830 defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each 2831 response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content). 2832 </p> 2833 <p id="rfc.section.9.6.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 9.6</a>) that lists the content-coding(s) applied. 2834 </p> 2835 <p id="rfc.section.9.6.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. 2836 </p> 2837 <p id="rfc.section.9.6.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). 2838 </p> 2839 <div id="rfc.iref.c.8"></div> 2840 <div id="rfc.iref.h.8"></div> 2841 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 2842 <p id="rfc.section.9.7.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 2843 that this might not be equivalent to all the languages used within the representation. 2844 </p> 2845 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 2846 </pre><p id="rfc.section.9.7.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 5.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 2847 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 2848 field is 2849 </p> 2850 <div id="rfc.figure.u.41"></div><pre class="text"> Content-Language: da 2851 </pre><p id="rfc.section.9.7.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 2852 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 2853 it is intended. 2854 </p> 2855 <p id="rfc.section.9.7.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented 2856 simultaneously in the original Maori and English versions, would call for 2857 </p> 2858 <div id="rfc.figure.u.42"></div><pre class="text"> Content-Language: mi, en 2859 </pre><p id="rfc.section.9.7.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 2860 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 2861 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 2862 </p> 2863 <p id="rfc.section.9.7.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 2864 </p> 2865 <div id="rfc.iref.c.9"></div> 2866 <div id="rfc.iref.h.9"></div> 2867 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 2868 <p id="rfc.section.9.8.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 2869 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 2870 would contain the same representation that is enclosed as payload in this message. 2871 </p> 2872 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2873 </pre><p id="rfc.section.9.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 2874 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 2875 </p> 2876 <p id="rfc.section.9.8.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 2877 payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 2878 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's 2879 response contains the new representation of that resource, thereby distinguishing it from representations that might only 2880 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the 2881 need for a subsequent GET request. 2882 </p> 2883 <p id="rfc.section.9.8.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 2884 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 2885 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation 2886 and the selected representation for this response can also be found at the identified URI. For other methods, such a Content-Location 2887 indicates that this representation contains a report on the action's status and the same report is available (for future access 2888 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 2889 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 2890 in the future. 2891 </p> 2892 <p id="rfc.section.9.8.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 2893 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 2894 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated 2895 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected 2896 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse 2897 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the 2898 latter semantics, it would have applied the PUT directly to the Content-Location URI. 2899 </p> 2900 <p id="rfc.section.9.8.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 2901 in other contexts, such as within source links or other metadata. 2902 </p> 2903 <p id="rfc.section.9.8.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 2904 to respond to later requests on that Content-Location URI. 2905 </p> 2906 <p id="rfc.section.9.8.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 2907 <div id="rfc.iref.c.10"></div> 2908 <div id="rfc.iref.h.10"></div> 2909 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 2910 <p id="rfc.section.9.9.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 2911 the media type is that which would have been sent had the request been a GET. 2912 </p> 2913 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 2914 </pre><p id="rfc.section.9.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 5.5</a>. An example of the field is 2915 </p> 2916 <div id="rfc.figure.u.45"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 2917 </pre><p id="rfc.section.9.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 7.3</a>. 2918 </p> 2608 2919 <div id="rfc.iref.d.3"></div> 2609 <div id="rfc.iref.h. 3"></div>2610 <h2 id="rfc.section.9. 2"><a href="#rfc.section.9.2">9.2</a> <a id="header.date" href="#header.date">Date</a></h2>2611 <p id="rfc.section.9. 2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2920 <div id="rfc.iref.h.11"></div> 2921 <h2 id="rfc.section.9.10"><a href="#rfc.section.9.10">9.10</a> <a id="header.date" href="#header.date">Date</a></h2> 2922 <p id="rfc.section.9.10.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2612 2923 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 5.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2613 2924 </p> 2614 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>2615 </pre><p id="rfc.section.9. 2.p.3">An example is</p>2616 <div id="rfc.figure.u. 28"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2617 </pre><p id="rfc.section.9. 2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:2925 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> 2926 </pre><p id="rfc.section.9.10.p.3">An example is</p> 2927 <div id="rfc.figure.u.47"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2928 </pre><p id="rfc.section.9.10.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2618 2929 </p> 2619 2930 <ol> … … 2626 2937 </li> 2627 2938 </ol> 2628 <p id="rfc.section.9. 2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.2629 </p> 2630 <p id="rfc.section.9. 2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it2939 <p id="rfc.section.9.10.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. 2940 </p> 2941 <p id="rfc.section.9.10.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it 2631 2942 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2632 2943 </p> 2633 <p id="rfc.section.9. 2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means2944 <p id="rfc.section.9.10.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means 2634 2945 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2635 2946 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2637 2948 </p> 2638 2949 <div id="rfc.iref.e.1"></div> 2639 <div id="rfc.iref.h. 4"></div>2640 <h2 id="rfc.section.9. 3"><a href="#rfc.section.9.3">9.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2>2641 <p id="rfc.section.9. 3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>2642 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>2950 <div id="rfc.iref.h.12"></div> 2951 <h2 id="rfc.section.9.11"><a href="#rfc.section.9.11">9.11</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 2952 <p id="rfc.section.9.11.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 2953 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 2643 2954 2644 2955 <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] … … 2648 2959 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2649 2960 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2650 </pre><p id="rfc.section.9. 3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand2961 </pre><p id="rfc.section.9.11.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2651 2962 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2652 2963 </p> 2653 <p id="rfc.section.9. 3.p.4">The only expectation defined by this specification is:</p>2654 <p id="rfc.section.9. 3.p.5"><span id="rfc.iref.108"></span><span id="rfc.iref.e.2"></span> 100-continue2964 <p id="rfc.section.9.11.p.4">The only expectation defined by this specification is:</p> 2965 <p id="rfc.section.9.11.p.5"><span id="rfc.iref.137"></span><span id="rfc.iref.e.2"></span> 100-continue 2655 2966 </p> 2656 2967 <ul class="empty"> 2657 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2658 </li> 2659 </ul> 2660 <p id="rfc.section.9. 3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>2661 <p id="rfc.section.9. 3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header2968 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2969 </li> 2970 </ul> 2971 <p id="rfc.section.9.11.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 2972 <p id="rfc.section.9.11.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 2662 2973 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2663 2974 </p> 2664 <p id="rfc.section.9. 3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>2975 <p id="rfc.section.9.11.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2665 2976 <div id="rfc.iref.f.1"></div> 2666 <div id="rfc.iref.h. 5"></div>2667 <h2 id="rfc.section.9. 4"><a href="#rfc.section.9.4">9.4</a> <a id="header.from" href="#header.from">From</a></h2>2668 <p id="rfc.section.9. 4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:2669 </p> 2670 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.41"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>2977 <div id="rfc.iref.h.13"></div> 2978 <h2 id="rfc.section.9.12"><a href="#rfc.section.9.12">9.12</a> <a id="header.from" href="#header.from">From</a></h2> 2979 <p id="rfc.section.9.12.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2980 </p> 2981 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2671 2982 2672 2983 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> 2673 </pre><p id="rfc.section.9. 4.p.3">An example is:</p>2674 <div id="rfc.figure.u. 31"></div><pre class="text"> From: webmaster@example.org2675 </pre><p id="rfc.section.9. 4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed2984 </pre><p id="rfc.section.9.12.p.3">An example is:</p> 2985 <div id="rfc.figure.u.50"></div><pre class="text"> From: webmaster@example.org 2986 </pre><p id="rfc.section.9.12.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 2676 2987 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving 2677 2988 end. 2678 2989 </p> 2679 <p id="rfc.section.9. 4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original2990 <p id="rfc.section.9.12.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 2680 2991 issuer's address <em class="bcp14">SHOULD</em> be used. 2681 2992 </p> 2682 <p id="rfc.section.9. 4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's2993 <p id="rfc.section.9.12.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 2683 2994 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2684 2995 any time prior to a request. 2685 2996 </p> 2686 2997 <div id="rfc.iref.l.1"></div> 2687 <div id="rfc.iref.h. 6"></div>2688 <h2 id="rfc.section.9. 5"><a href="#rfc.section.9.5">9.5</a> <a id="header.location" href="#header.location">Location</a></h2>2689 <p id="rfc.section.9. 5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.2690 </p> 2691 <div id="rfc.figure.u. 32"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>2692 </pre><p id="rfc.section.9. 5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,2998 <div id="rfc.iref.h.14"></div> 2999 <h2 id="rfc.section.9.13"><a href="#rfc.section.9.13">9.13</a> <a id="header.location" href="#header.location">Location</a></h2> 3000 <p id="rfc.section.9.13.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 3001 </p> 3002 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 3003 </pre><p id="rfc.section.9.13.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2693 3004 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2694 3005 </p> 2695 <p id="rfc.section.9. 5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,3006 <p id="rfc.section.9.13.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, 2696 3007 then the original URI's fragment identifier is added to the final value. 2697 3008 </p> 2698 <div id="rfc.figure.u. 33"></div>3009 <div id="rfc.figure.u.52"></div> 2699 3010 <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim 2700 3011 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2701 <div id="rfc.figure.u. 34"></div>3012 <div id="rfc.figure.u.53"></div> 2702 3013 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2703 3014 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2704 <div class="note" id="rfc.section.9. 5.p.7">3015 <div class="note" id="rfc.section.9.13.p.7"> 2705 3016 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2706 3017 or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.2</a>). 2707 3018 </p> 2708 3019 </div> 2709 <p id="rfc.section.9. 5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears3020 <p id="rfc.section.9.13.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2710 3021 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2711 3022 </p> 2712 <div class="note" id="rfc.section.9. 5.p.9">2713 <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 9. 17</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.3023 <div class="note" id="rfc.section.9.13.p.9"> 3024 <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2714 3025 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2715 3026 </p> 2716 3027 </div> 2717 3028 <div id="rfc.iref.m.9"></div> 2718 <div id="rfc.iref.h. 7"></div>2719 <h2 id="rfc.section.9. 6"><a href="#rfc.section.9.6">9.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>2720 <p id="rfc.section.9. 6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 2.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting3029 <div id="rfc.iref.h.15"></div> 3030 <h2 id="rfc.section.9.14"><a href="#rfc.section.9.14">9.14</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 3031 <p id="rfc.section.9.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 2.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2721 3032 to trace a request which appears to be failing or looping mid-chain. 2722 3033 </p> 2723 <div id="rfc.figure.u. 35"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2724 </pre><p id="rfc.section.9. 6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>2725 <p id="rfc.section.9. 6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).2726 </p> 2727 <p id="rfc.section.9. 6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.3034 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 3035 </pre><p id="rfc.section.9.14.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 3036 <p id="rfc.section.9.14.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 3037 </p> 3038 <p id="rfc.section.9.14.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 2728 3039 </p> 2729 3040 <div id="rfc.iref.r.2"></div> 2730 <div id="rfc.iref.h. 8"></div>2731 <h2 id="rfc.section.9. 7"><a href="#rfc.section.9.7">9.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2>2732 <p id="rfc.section.9. 7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained3041 <div id="rfc.iref.h.16"></div> 3042 <h2 id="rfc.section.9.15"><a href="#rfc.section.9.15">9.15</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 3043 <p id="rfc.section.9.15.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained 2733 3044 (the "referrer", although the header field is misspelled.). 2734 3045 </p> 2735 <p id="rfc.section.9. 7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,3046 <p id="rfc.section.9.15.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 2736 3047 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2737 3048 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2738 3049 </p> 2739 <p id="rfc.section.9. 7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer3050 <p id="rfc.section.9.15.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer 2740 3051 field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 2741 3052 non-HTTP URIs (e.g., FTP). 2742 3053 </p> 2743 <div id="rfc.figure.u. 36"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>2744 </pre><p id="rfc.section.9. 7.p.5">Example:</p>2745 <div id="rfc.figure.u. 37"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html2746 </pre><p id="rfc.section.9. 7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations.3054 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.57"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 3055 </pre><p id="rfc.section.9.15.p.5">Example:</p> 3056 <div id="rfc.figure.u.56"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 3057 </pre><p id="rfc.section.9.15.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations. 2747 3058 </p> 2748 3059 <div id="rfc.iref.r.3"></div> 2749 <div id="rfc.iref.h. 9"></div>2750 <h2 id="rfc.section.9. 8"><a href="#rfc.section.9.8">9.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>2751 <p id="rfc.section.9. 8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected3060 <div id="rfc.iref.h.17"></div> 3061 <h2 id="rfc.section.9.16"><a href="#rfc.section.9.16">9.16</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 3062 <p id="rfc.section.9.16.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2752 3063 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing 2753 3064 the redirected request. 2754 3065 </p> 2755 <p id="rfc.section.9. 8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>2756 <div id="rfc.figure.u. 38"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>3066 <p id="rfc.section.9.16.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 3067 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.58"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2757 3068 </pre><div id="rule.delta-seconds"> 2758 <p id="rfc.section.9. 8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>3069 <p id="rfc.section.9.16.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2759 3070 </div> 2760 <div id="rfc.figure.u. 39"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2761 </pre><p id="rfc.section.9. 8.p.6">Two examples of its use are</p>2762 <div id="rfc.figure.u. 40"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT3071 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.59"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 3072 </pre><p id="rfc.section.9.16.p.6">Two examples of its use are</p> 3073 <div id="rfc.figure.u.59"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2763 3074 Retry-After: 120 2764 </pre><p id="rfc.section.9. 8.p.8">In the latter example, the delay is 2 minutes.</p>3075 </pre><p id="rfc.section.9.16.p.8">In the latter example, the delay is 2 minutes.</p> 2765 3076 <div id="rfc.iref.s.39"></div> 2766 <div id="rfc.iref.h.1 0"></div>2767 <h2 id="rfc.section.9. 9"><a href="#rfc.section.9.9">9.9</a> <a id="header.server" href="#header.server">Server</a></h2>2768 <p id="rfc.section.9. 9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>2769 <p id="rfc.section.9. 9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 5.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for3077 <div id="rfc.iref.h.18"></div> 3078 <h2 id="rfc.section.9.17"><a href="#rfc.section.9.17">9.17</a> <a id="header.server" href="#header.server">Server</a></h2> 3079 <p id="rfc.section.9.17.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 3080 <p id="rfc.section.9.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 5.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2770 3081 identifying the application. 2771 3082 </p> 2772 <div id="rfc.figure.u. 41"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2773 </pre><p id="rfc.section.9. 9.p.4">Example:</p>2774 <div id="rfc.figure.u. 42"></div><pre class="text"> Server: CERN/3.0 libwww/2.172775 </pre><p id="rfc.section.9. 9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2776 </p> 2777 <div class="note" id="rfc.section.9. 9.p.7">3083 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.60"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 3084 </pre><p id="rfc.section.9.17.p.4">Example:</p> 3085 <div id="rfc.figure.u.61"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 3086 </pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 3087 </p> 3088 <div class="note" id="rfc.section.9.17.p.7"> 2778 3089 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2779 3090 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable … … 2782 3093 </div> 2783 3094 <div id="rfc.iref.u.1"></div> 2784 <div id="rfc.iref.h.1 1"></div>2785 <h2 id="rfc.section.9.1 0"><a href="#rfc.section.9.10">9.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>2786 <p id="rfc.section.9.1 0.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.2787 </p> 2788 <p id="rfc.section.9.1 0.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular3095 <div id="rfc.iref.h.19"></div> 3096 <h2 id="rfc.section.9.18"><a href="#rfc.section.9.18">9.18</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 3097 <p id="rfc.section.9.18.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests. 3098 </p> 3099 <p id="rfc.section.9.18.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular 2789 3100 user agent limitations. 2790 3101 </p> 2791 <p id="rfc.section.9.1 0.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 5.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance3102 <p id="rfc.section.9.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 5.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2792 3103 for identifying the application. 2793 3104 </p> 2794 <p id="rfc.section.9.1 0.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly3105 <p id="rfc.section.9.18.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly 2795 3106 fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed 2796 3107 User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. 2797 3108 </p> 2798 <p id="rfc.section.9.1 0.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility3109 <p id="rfc.section.9.18.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility 2799 3110 with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; 2800 3111 doing so makes the field value more difficult to parse. 2801 3112 </p> 2802 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2803 </pre><p id="rfc.section.9.10.p.7">Example:</p> 2804 <div id="rfc.figure.u.44"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2805 </pre><div id="rfc.iref.a.2"></div> 2806 <div id="rfc.iref.h.12"></div> 2807 <h2 id="rfc.section.9.11"><a href="#rfc.section.9.11">9.11</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 2808 <p id="rfc.section.9.11.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields 2809 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 2810 for an in-line image. 2811 </p> 2812 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 2813 2814 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" 2815 / ( <a href="#media.types" class="smpl">type</a> "/" "*" ) 2816 / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> ) 2817 ) *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 2818 <a href="#header.accept" class="smpl">accept-params</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> *( <a href="#header.accept" class="smpl">accept-ext</a> ) 2819 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ] 2820 </pre><p id="rfc.section.9.11.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 2821 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 2822 </p> 2823 <p id="rfc.section.9.11.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 2824 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 2825 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (qvalue;). The 2826 default value is q=1. 2827 </p> 2828 <div class="note" id="rfc.section.9.11.p.5"> 2829 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 2830 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 2831 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 2832 in Accept. Future media types are discouraged from registering any parameter named "q". 2833 </p> 2834 </div> 2835 <p id="rfc.section.9.11.p.6">The example</p> 2836 <div id="rfc.figure.u.46"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 2837 </pre><p id="rfc.section.9.11.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 2838 quality". 2839 </p> 2840 <p id="rfc.section.9.11.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept 2841 header field is present in a request and none of the available representations for the response have a media type that is 2842 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 2843 the response as if it is not subject to content negotiation. 2844 </p> 2845 <p id="rfc.section.9.11.p.10">A more elaborate example is</p> 2846 <div id="rfc.figure.u.47"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 2847 text/x-dvi; q=0.8, text/x-c 2848 </pre><p id="rfc.section.9.11.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 2849 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 2850 </p> 2851 <p id="rfc.section.9.11.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 2852 to a given type, the most specific reference has precedence. For example, 2853 </p> 2854 <div id="rfc.figure.u.48"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 2855 </pre><p id="rfc.section.9.11.p.15">have the following precedence: </p> 2856 <ol> 2857 <li>text/plain;format=flowed</li> 2858 <li>text/plain</li> 2859 <li>text/*</li> 2860 <li>*/*</li> 2861 </ol> 2862 <p id="rfc.section.9.11.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 2863 which matches that type. For example, 2864 </p> 2865 <div id="rfc.figure.u.49"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 2866 text/html;level=2;q=0.4, */*;q=0.5 2867 </pre><p id="rfc.section.9.11.p.18">would cause the following values to be associated:</p> 2868 <div id="rfc.table.u.7"> 2869 <table class="tt full left" cellpadding="3" cellspacing="0"> 2870 <thead> 2871 <tr> 2872 <th>Media Type</th> 2873 <th>Quality Value</th> 2874 </tr> 2875 </thead> 2876 <tbody> 2877 <tr> 2878 <td class="left">text/html;level=1</td> 2879 <td class="left">1</td> 2880 </tr> 2881 <tr> 2882 <td class="left">text/html</td> 2883 <td class="left">0.7</td> 2884 </tr> 2885 <tr> 2886 <td class="left">text/plain</td> 2887 <td class="left">0.3</td> 2888 </tr> 2889 <tr> 2890 <td class="left">image/jpeg</td> 2891 <td class="left">0.5</td> 2892 </tr> 2893 <tr> 2894 <td class="left">text/html;level=2</td> 2895 <td class="left">0.4</td> 2896 </tr> 2897 <tr> 2898 <td class="left">text/html;level=3</td> 2899 <td class="left">0.7</td> 2900 </tr> 2901 </tbody> 2902 </table> 2903 </div> 2904 <p id="rfc.section.9.11.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 2905 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 2906 </p> 2907 <div id="rfc.iref.a.3"></div> 2908 <div id="rfc.iref.h.13"></div> 2909 <h2 id="rfc.section.9.12"><a href="#rfc.section.9.12">9.12</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 2910 <p id="rfc.section.9.12.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response 2911 payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal 2912 that capability to a server which is capable of representing documents in those character encodings. 2913 </p> 2914 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 2915 [ <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> ] ) 2916 </pre><p id="rfc.section.9.12.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 2917 example is 2918 </p> 2919 <div id="rfc.figure.u.51"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 2920 </pre><p id="rfc.section.9.12.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere 2921 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly 2922 mentioned get a quality value of 0. 2923 </p> 2924 <p id="rfc.section.9.12.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response. 2925 If an Accept-Charset header field is present in a request and none of the available representations for the response have 2926 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 2927 field by treating the response as if it is not subject to content negotiation. 2928 </p> 2929 <div id="rfc.iref.a.4"></div> 2930 <div id="rfc.iref.h.14"></div> 2931 <h2 id="rfc.section.9.13"><a href="#rfc.section.9.13">9.13</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 2932 <p id="rfc.section.9.13.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 5.4</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when 2933 no encoding is preferred. 2934 </p> 2935 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></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> ] ) 2936 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 2937 </pre><p id="rfc.section.9.13.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. 2938 </p> 2939 <p id="rfc.section.9.13.p.4">For example,</p> 2940 <div id="rfc.figure.u.53"></div><pre class="text"> Accept-Encoding: compress, gzip 2941 Accept-Encoding: 2942 Accept-Encoding: * 2943 Accept-Encoding: compress;q=0.5, gzip;q=1.0 2944 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 2945 </pre><p id="rfc.section.9.13.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using 2946 these rules: 2947 </p> 2948 <ol> 2949 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 2950 field. 2951 </li> 2952 <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding 2953 field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". 2954 </li> 2955 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 2956 unless it is accompanied by a qvalue of 0. (As defined in qvalue;, a qvalue of 0 means "not acceptable".) 2957 </li> 2958 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 2959 </ol> 2960 <p id="rfc.section.9.13.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 2961 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 2962 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. 2963 </p> 2964 <p id="rfc.section.9.13.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response, 2965 but a representation without content-coding is preferred for compatibility with the widest variety of user agents. 2966 </p> 2967 <div class="note" id="rfc.section.9.13.p.9"> 2968 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 2969 not work and are not permitted with x-gzip or x-compress. 2970 </p> 2971 </div> 2972 <div id="rfc.iref.a.5"></div> 2973 <div id="rfc.iref.h.15"></div> 2974 <h2 id="rfc.section.9.14"><a href="#rfc.section.9.14">9.14</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 2975 <p id="rfc.section.9.14.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred 2976 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 5.6</a>. 2977 </p> 2978 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 2979 1#( <a href="#header.accept-language" class="smpl">language-range</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> ] ) 2980 <a href="#header.accept-language" class="smpl">language-range</a> = 2981 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> 2982 </pre><p id="rfc.section.9.14.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the 2983 languages specified by that range. The quality value defaults to "q=1". For example, 2984 </p> 2985 <div id="rfc.figure.u.55"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 2986 </pre><p id="rfc.section.9.14.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 2987 </p> 2988 <p id="rfc.section.9.14.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. 2989 </p> 2990 <div class="note" id="rfc.section.9.14.p.7"> 2991 <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2992 </p> 2993 </div> 2994 <p id="rfc.section.9.14.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 2995 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section 11.5</a>. 2996 </p> 2997 <p id="rfc.section.9.14.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 2998 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 2999 </p> 3000 <div class="note" id="rfc.section.9.14.p.10"> 3001 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 3002 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, 3003 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 3004 A user agent might suggest in such a case to add "en" to get the best matching behavior. 3005 </p> 3006 </div> 3007 <div id="rfc.iref.c.7"></div> 3008 <div id="rfc.iref.h.16"></div> 3009 <h2 id="rfc.section.9.15"><a href="#rfc.section.9.15">9.15</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 3010 <p id="rfc.section.9.15.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 3011 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 3012 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 3013 identity of its underlying media type. 3014 </p> 3015 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.58"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 3016 </pre><p id="rfc.section.9.15.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 5.4</a>. An example of its use is 3017 </p> 3018 <div id="rfc.figure.u.57"></div><pre class="text"> Content-Encoding: gzip 3019 </pre><p id="rfc.section.9.15.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 3020 and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 3021 directive is present in the message. 3022 </p> 3023 <p id="rfc.section.9.15.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would 3024 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 3025 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin 3026 server might choose to publish the same payload data as multiple representations that differ only in whether the coding is 3027 defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each 3028 response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content). 3029 </p> 3030 <p id="rfc.section.9.15.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 9.15</a>) that lists the content-coding(s) applied. 3031 </p> 3032 <p id="rfc.section.9.15.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. 3033 </p> 3034 <p id="rfc.section.9.15.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). 3035 </p> 3036 <div id="rfc.iref.c.8"></div> 3037 <div id="rfc.iref.h.17"></div> 3038 <h2 id="rfc.section.9.16"><a href="#rfc.section.9.16">9.16</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 3039 <p id="rfc.section.9.16.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 3040 that this might not be equivalent to all the languages used within the representation. 3041 </p> 3042 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.59"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 3043 </pre><p id="rfc.section.9.16.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 5.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 3044 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 3045 field is 3046 </p> 3047 <div id="rfc.figure.u.59"></div><pre class="text"> Content-Language: da 3048 </pre><p id="rfc.section.9.16.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 3049 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 3050 it is intended. 3051 </p> 3052 <p id="rfc.section.9.16.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented 3053 simultaneously in the original Maori and English versions, would call for 3054 </p> 3055 <div id="rfc.figure.u.60"></div><pre class="text"> Content-Language: mi, en 3056 </pre><p id="rfc.section.9.16.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 3057 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 3058 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 3059 </p> 3060 <p id="rfc.section.9.16.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 3061 </p> 3062 <div id="rfc.iref.c.9"></div> 3063 <div id="rfc.iref.h.18"></div> 3064 <h2 id="rfc.section.9.17"><a href="#rfc.section.9.17">9.17</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 3065 <p id="rfc.section.9.17.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 3066 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 3067 would contain the same representation that is enclosed as payload in this message. 3068 </p> 3069 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.60"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 3070 </pre><p id="rfc.section.9.17.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 3071 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 3072 </p> 3073 <p id="rfc.section.9.17.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 3074 payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 3075 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's 3076 response contains the new representation of that resource, thereby distinguishing it from representations that might only 3077 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the 3078 need for a subsequent GET request. 3079 </p> 3080 <p id="rfc.section.9.17.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 3081 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 3082 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation 3083 and the selected representation for this response can also be found at the identified URI. For other methods, such a Content-Location 3084 indicates that this representation contains a report on the action's status and the same report is available (for future access 3085 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 3086 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 3087 in the future. 3088 </p> 3089 <p id="rfc.section.9.17.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 3090 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 3091 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated 3092 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected 3093 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse 3094 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the 3095 latter semantics, it would have applied the PUT directly to the Content-Location URI. 3096 </p> 3097 <p id="rfc.section.9.17.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 3098 in other contexts, such as within source links or other metadata. 3099 </p> 3100 <p id="rfc.section.9.17.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 3101 to respond to later requests on that Content-Location URI. 3102 </p> 3103 <p id="rfc.section.9.17.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 3104 <div id="rfc.iref.c.10"></div> 3105 <div id="rfc.iref.h.19"></div> 3106 <h2 id="rfc.section.9.18"><a href="#rfc.section.9.18">9.18</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 3107 <p id="rfc.section.9.18.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 3108 the media type is that which would have been sent had the request been a GET. 3109 </p> 3110 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.61"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 3111 </pre><p id="rfc.section.9.18.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 5.5</a>. An example of the field is 3112 </p> 3113 <div id="rfc.figure.u.63"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 3114 </pre><p id="rfc.section.9.18.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 7.3</a>. 3115 </p> 3116 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 3113 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.61"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 3114 </pre><p id="rfc.section.9.18.p.7">Example:</p> 3115 <div id="rfc.figure.u.63"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 3116 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 3117 3117 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> 3118 3118 <p id="rfc.section.10.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document. … … 3436 3436 <td class="left">http</td> 3437 3437 <td class="left">standard</td> 3438 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Section 9.1 1</a>3438 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Section 9.1</a> 3439 3439 </td> 3440 3440 </tr> … … 3443 3443 <td class="left">http</td> 3444 3444 <td class="left">standard</td> 3445 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 9. 12</a>3445 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 9.2</a> 3446 3446 </td> 3447 3447 </tr> … … 3450 3450 <td class="left">http</td> 3451 3451 <td class="left">standard</td> 3452 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section 9. 13</a>3452 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section 9.3</a> 3453 3453 </td> 3454 3454 </tr> … … 3457 3457 <td class="left">http</td> 3458 3458 <td class="left">standard</td> 3459 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Section 9. 14</a>3459 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Section 9.4</a> 3460 3460 </td> 3461 3461 </tr> … … 3464 3464 <td class="left">http</td> 3465 3465 <td class="left">standard</td> 3466 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 9. 1</a>3466 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 9.5</a> 3467 3467 </td> 3468 3468 </tr> … … 3471 3471 <td class="left">http</td> 3472 3472 <td class="left">standard</td> 3473 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section 9. 15</a>3473 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section 9.6</a> 3474 3474 </td> 3475 3475 </tr> … … 3478 3478 <td class="left">http</td> 3479 3479 <td class="left">standard</td> 3480 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 9. 16</a>3480 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 9.7</a> 3481 3481 </td> 3482 3482 </tr> … … 3485 3485 <td class="left">http</td> 3486 3486 <td class="left">standard</td> 3487 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section 9. 17</a>3487 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section 9.8</a> 3488 3488 </td> 3489 3489 </tr> … … 3492 3492 <td class="left">http</td> 3493 3493 <td class="left">standard</td> 3494 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section 9. 18</a>3494 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section 9.9</a> 3495 3495 </td> 3496 3496 </tr> … … 3499 3499 <td class="left">http</td> 3500 3500 <td class="left">standard</td> 3501 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9. 2</a>3501 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.10</a> 3502 3502 </td> 3503 3503 </tr> … … 3506 3506 <td class="left">http</td> 3507 3507 <td class="left">standard</td> 3508 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 9. 3</a>3508 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 9.11</a> 3509 3509 </td> 3510 3510 </tr> … … 3513 3513 <td class="left">http</td> 3514 3514 <td class="left">standard</td> 3515 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 9. 4</a>3515 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 9.12</a> 3516 3516 </td> 3517 3517 </tr> … … 3520 3520 <td class="left">http</td> 3521 3521 <td class="left">standard</td> 3522 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9. 5</a>3522 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.13</a> 3523 3523 </td> 3524 3524 </tr> … … 3534 3534 <td class="left">http</td> 3535 3535 <td class="left">standard</td> 3536 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 9. 6</a>3536 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 9.14</a> 3537 3537 </td> 3538 3538 </tr> … … 3541 3541 <td class="left">http</td> 3542 3542 <td class="left">standard</td> 3543 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 9. 7</a>3543 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 9.15</a> 3544 3544 </td> 3545 3545 </tr> … … 3548 3548 <td class="left">http</td> 3549 3549 <td class="left">standard</td> 3550 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 9. 8</a>3550 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 9.16</a> 3551 3551 </td> 3552 3552 </tr> … … 3555 3555 <td class="left">http</td> 3556 3556 <td class="left">standard</td> 3557 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 9. 9</a>3557 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 9.17</a> 3558 3558 </td> 3559 3559 </tr> … … 3562 3562 <td class="left">http</td> 3563 3563 <td class="left">standard</td> 3564 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.1 0</a>3564 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.18</a> 3565 3565 </td> 3566 3566 </tr> … … 3607 3607 <td class="left">identity</td> 3608 3608 <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td> 3609 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section 9. 13</a>3609 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section 9.3</a> 3610 3610 </td> 3611 3611 </tr> … … 3641 3641 of From and Referer information. 3642 3642 </p> 3643 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 9.1 0</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might3643 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 9.18</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 3644 3644 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3645 3645 no better mechanism. … … 3994 3994 </p> 3995 3995 <p id="rfc.section.C.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3996 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9. 1</a>)3996 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.5</a>) 3997 3997 </p> 3998 3998 <p id="rfc.section.C.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3999 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9. 3</a>)3999 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.11</a>) 4000 4000 </p> 4001 4001 <p id="rfc.section.C.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 4002 4002 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 4003 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9. 5</a>)4004 </p> 4005 <p id="rfc.section.C.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9. 6</a>)4006 </p> 4007 <p id="rfc.section.C.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9. 7</a>)4003 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.13</a>) 4004 </p> 4005 <p id="rfc.section.C.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.14</a>) 4006 </p> 4007 <p id="rfc.section.C.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.15</a>) 4008 4008 </p> 4009 4009 <p id="rfc.section.C.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 4010 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.57"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9. 9</a>)4010 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.57"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.17</a>) 4011 4011 </p> 4012 4012 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>) … … 4021 4021 and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 4022 4022 </p> 4023 <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9. 12</a>)4023 <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9.2</a>) 4024 4024 </p> 4025 4025 <p id="rfc.section.C.p.23">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken 4026 4026 servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking 4027 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 9. 17</a>)4027 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 9.8</a>) 4028 4028 </p> 4029 4029 <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) … … 4751 4751 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4752 4752 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.24"><b>4.3.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li> 4753 <li>100-continue (expect value) <a href="#rfc.iref.1 08"><b>9.3</b></a></li>4753 <li>100-continue (expect value) <a href="#rfc.iref.137"><b>9.11</b></a></li> 4754 4754 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.25"><b>4.3.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li> 4755 4755 </ul> … … 4802 4802 </li> 4803 4803 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 4804 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">5.5</a>, <a href="#rfc.xref.header.accept.3">8.1</a>, <a href="#rfc.iref.a. 2"><b>9.11</b></a>, <a href="#rfc.xref.header.accept.4">10.3</a></li>4805 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.xref.header.accept-charset.2">8.1</a>, <a href="#rfc.iref.a. 3"><b>9.12</b></a>, <a href="#rfc.xref.header.accept-charset.3">10.3</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>4806 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">5.4</a>, <a href="#rfc.xref.header.accept-encoding.3">8.1</a>, <a href="#rfc.iref.a. 4"><b>9.13</b></a>, <a href="#rfc.xref.header.accept-encoding.4">10.3</a>, <a href="#rfc.xref.header.accept-encoding.5">10.4</a></li>4807 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.xref.header.accept-language.2">8.1</a>, <a href="#rfc.iref.a. 5"><b>9.14</b></a>, <a href="#rfc.xref.header.accept-language.3">10.3</a></li>4808 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a. 1"><b>9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li>4804 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">5.5</a>, <a href="#rfc.xref.header.accept.3">8.1</a>, <a href="#rfc.iref.a.1"><b>9.1</b></a>, <a href="#rfc.xref.header.accept.4">10.3</a></li> 4805 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.xref.header.accept-charset.2">8.1</a>, <a href="#rfc.iref.a.2"><b>9.2</b></a>, <a href="#rfc.xref.header.accept-charset.3">10.3</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li> 4806 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">5.4</a>, <a href="#rfc.xref.header.accept-encoding.3">8.1</a>, <a href="#rfc.iref.a.3"><b>9.3</b></a>, <a href="#rfc.xref.header.accept-encoding.4">10.3</a>, <a href="#rfc.xref.header.accept-encoding.5">10.4</a></li> 4807 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.xref.header.accept-language.2">8.1</a>, <a href="#rfc.iref.a.4"><b>9.4</b></a>, <a href="#rfc.xref.header.accept-language.3">10.3</a></li> 4808 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.5"><b>9.5</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li> 4809 4809 </ul> 4810 4810 </li> … … 4820 4820 <li>CONNECT method <a href="#rfc.iref.c.2"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">10.1</a>, <a href="#rfc.xref.CONNECT.2">C</a></li> 4821 4821 <li>content negotiation <a href="#rfc.iref.c.1">1.1</a></li> 4822 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.c.7"><b>9. 15</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.15</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li>4823 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.c.8"><b>9. 16</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li>4824 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc. xref.header.content-location.3">9.5</a>, <a href="#rfc.iref.c.9"><b>9.17</b></a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4822 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.c.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.6</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li> 4823 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.c.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li> 4824 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc.iref.c.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.3">9.13</a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4825 4825 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.11">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4826 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.c.10"><b>9. 18</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li>4826 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.c.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li> 4827 4827 </ul> 4828 4828 </li> 4829 4829 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 4830 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.3"><b>9. 2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>4830 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.3"><b>9.10</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li> 4831 4831 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5.4</a></li> 4832 4832 <li>DELETE method <a href="#rfc.iref.d.1"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">10.1</a></li> … … 4835 4835 </li> 4836 4836 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 4837 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.e.1"><b>9. 3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li>4837 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.e.1"><b>9.11</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li> 4838 4838 <li>Expect Values 4839 4839 <ul> 4840 <li>100-continue <a href="#rfc.iref.e.2"><b>9. 3</b></a></li>4840 <li>100-continue <a href="#rfc.iref.e.2"><b>9.11</b></a></li> 4841 4841 </ul> 4842 4842 </li> … … 4844 4844 </li> 4845 4845 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 4846 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>9. 4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>4846 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>9.12</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li> 4847 4847 </ul> 4848 4848 </li> … … 4851 4851 <li><tt>Grammar</tt> 4852 4852 <ul> 4853 <li><tt>Accept</tt> <a href="#rfc.iref.g. 49"><b>9.11</b></a></li>4854 <li><tt>Accept-Charset</tt> <a href="#rfc.iref.g. 53"><b>9.12</b></a></li>4855 <li><tt>Accept-Encoding</tt> <a href="#rfc.iref.g. 54"><b>9.13</b></a></li>4856 <li><tt>accept-ext</tt> <a href="#rfc.iref.g. 52"><b>9.11</b></a></li>4857 <li><tt>Accept-Language</tt> <a href="#rfc.iref.g. 56"><b>9.14</b></a></li>4858 <li><tt>accept-params</tt> <a href="#rfc.iref.g. 51"><b>9.11</b></a></li>4859 <li><tt>Allow</tt> <a href="#rfc.iref.g. 34"><b>9.1</b></a></li>4853 <li><tt>Accept</tt> <a href="#rfc.iref.g.34"><b>9.1</b></a></li> 4854 <li><tt>Accept-Charset</tt> <a href="#rfc.iref.g.38"><b>9.2</b></a></li> 4855 <li><tt>Accept-Encoding</tt> <a href="#rfc.iref.g.39"><b>9.3</b></a></li> 4856 <li><tt>accept-ext</tt> <a href="#rfc.iref.g.37"><b>9.1</b></a></li> 4857 <li><tt>Accept-Language</tt> <a href="#rfc.iref.g.41"><b>9.4</b></a></li> 4858 <li><tt>accept-params</tt> <a href="#rfc.iref.g.36"><b>9.1</b></a></li> 4859 <li><tt>Allow</tt> <a href="#rfc.iref.g.43"><b>9.5</b></a></li> 4860 4860 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b>5.1</b></a></li> 4861 4861 <li><tt>attribute</tt> <a href="#rfc.iref.g.31"><b>5.5</b></a></li> 4862 4862 <li><tt>charset</tt> <a href="#rfc.iref.g.24"><b>5.3</b></a></li> 4863 <li><tt>codings</tt> <a href="#rfc.iref.g. 55"><b>9.13</b></a></li>4863 <li><tt>codings</tt> <a href="#rfc.iref.g.40"><b>9.3</b></a></li> 4864 4864 <li><tt>content-coding</tt> <a href="#rfc.iref.g.25"><b>5.4</b></a></li> 4865 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g. 58"><b>9.15</b></a></li>4866 <li><tt>Content-Language</tt> <a href="#rfc.iref.g. 59"><b>9.16</b></a></li>4867 <li><tt>Content-Location</tt> <a href="#rfc.iref.g. 60"><b>9.17</b></a></li>4868 <li><tt>Content-Type</tt> <a href="#rfc.iref.g. 61"><b>9.18</b></a></li>4869 <li><tt>Date</tt> <a href="#rfc.iref.g. 35"><b>9.2</b></a></li>4865 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g.44"><b>9.6</b></a></li> 4866 <li><tt>Content-Language</tt> <a href="#rfc.iref.g.45"><b>9.7</b></a></li> 4867 <li><tt>Content-Location</tt> <a href="#rfc.iref.g.46"><b>9.8</b></a></li> 4868 <li><tt>Content-Type</tt> <a href="#rfc.iref.g.47"><b>9.9</b></a></li> 4869 <li><tt>Date</tt> <a href="#rfc.iref.g.48"><b>9.10</b></a></li> 4870 4870 <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b>5.1</b></a></li> 4871 4871 <li><tt>day</tt> <a href="#rfc.iref.g.15"><b>5.1</b></a></li> 4872 4872 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b>5.1</b></a></li> 4873 4873 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b>5.1</b></a></li> 4874 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g. 46"><b>9.8</b></a></li>4875 <li><tt>Expect</tt> <a href="#rfc.iref.g. 36"><b>9.3</b></a></li>4876 <li><tt>expect-name</tt> <a href="#rfc.iref.g. 40"><b>9.3</b></a></li>4877 <li><tt>expect-param</tt> <a href="#rfc.iref.g. 38"><b>9.3</b></a></li>4878 <li><tt>expect-value</tt> <a href="#rfc.iref.g. 39"><b>9.3</b></a></li>4879 <li><tt>expectation</tt> <a href="#rfc.iref.g. 37"><b>9.3</b></a></li>4874 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.59"><b>9.16</b></a></li> 4875 <li><tt>Expect</tt> <a href="#rfc.iref.g.49"><b>9.11</b></a></li> 4876 <li><tt>expect-name</tt> <a href="#rfc.iref.g.53"><b>9.11</b></a></li> 4877 <li><tt>expect-param</tt> <a href="#rfc.iref.g.51"><b>9.11</b></a></li> 4878 <li><tt>expect-value</tt> <a href="#rfc.iref.g.52"><b>9.11</b></a></li> 4879 <li><tt>expectation</tt> <a href="#rfc.iref.g.50"><b>9.11</b></a></li> 4880 4880 <li><tt>extension-code</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> 4881 <li><tt>From</tt> <a href="#rfc.iref.g. 41"><b>9.4</b></a></li>4881 <li><tt>From</tt> <a href="#rfc.iref.g.54"><b>9.12</b></a></li> 4882 4882 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b>5.1</b></a></li> 4883 4883 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b>5.1</b></a></li> 4884 4884 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b>5.1</b></a></li> 4885 <li><tt>language-range</tt> <a href="#rfc.iref.g. 57"><b>9.14</b></a></li>4885 <li><tt>language-range</tt> <a href="#rfc.iref.g.42"><b>9.4</b></a></li> 4886 4886 <li><tt>language-tag</tt> <a href="#rfc.iref.g.33"><b>5.6</b></a></li> 4887 <li><tt>Location</tt> <a href="#rfc.iref.g. 42"><b>9.5</b></a></li>4888 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g. 43"><b>9.6</b></a></li>4889 <li><tt>media-range</tt> <a href="#rfc.iref.g. 50"><b>9.11</b></a></li>4887 <li><tt>Location</tt> <a href="#rfc.iref.g.55"><b>9.13</b></a></li> 4888 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.56"><b>9.14</b></a></li> 4889 <li><tt>media-range</tt> <a href="#rfc.iref.g.35"><b>9.1</b></a></li> 4890 4890 <li><tt>media-type</tt> <a href="#rfc.iref.g.27"><b>5.5</b></a></li> 4891 4891 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> … … 4898 4898 <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b>5.2</b></a></li> 4899 4899 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.5"><b>4</b></a></li> 4900 <li><tt>Referer</tt> <a href="#rfc.iref.g. 44"><b>9.7</b></a></li>4901 <li><tt>Retry-After</tt> <a href="#rfc.iref.g. 45"><b>9.8</b></a></li>4900 <li><tt>Referer</tt> <a href="#rfc.iref.g.57"><b>9.15</b></a></li> 4901 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.58"><b>9.16</b></a></li> 4902 4902 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b>5.1</b></a></li> 4903 4903 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b>5.1</b></a></li> 4904 4904 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b>5.1</b></a></li> 4905 <li><tt>Server</tt> <a href="#rfc.iref.g. 47"><b>9.9</b></a></li>4905 <li><tt>Server</tt> <a href="#rfc.iref.g.60"><b>9.17</b></a></li> 4906 4906 <li><tt>status-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> 4907 4907 <li><tt>subtype</tt> <a href="#rfc.iref.g.29"><b>5.5</b></a></li> 4908 4908 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b>5.1</b></a></li> 4909 4909 <li><tt>type</tt> <a href="#rfc.iref.g.28"><b>5.5</b></a></li> 4910 <li><tt>User-Agent</tt> <a href="#rfc.iref.g. 48"><b>9.10</b></a></li>4910 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.61"><b>9.18</b></a></li> 4911 4911 <li><tt>value</tt> <a href="#rfc.iref.g.32"><b>5.5</b></a></li> 4912 4912 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b>5.1</b></a></li> … … 4920 4920 <li>Header Fields 4921 4921 <ul> 4922 <li>Accept <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">5.5</a>, <a href="#rfc.xref.header.accept.3">8.1</a>, <a href="#rfc.iref.h. 12"><b>9.11</b></a>, <a href="#rfc.xref.header.accept.4">10.3</a></li>4923 <li>Accept-Charset <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.xref.header.accept-charset.2">8.1</a>, <a href="#rfc.iref.h. 13"><b>9.12</b></a>, <a href="#rfc.xref.header.accept-charset.3">10.3</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>4924 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">5.4</a>, <a href="#rfc.xref.header.accept-encoding.3">8.1</a>, <a href="#rfc.iref.h. 14"><b>9.13</b></a>, <a href="#rfc.xref.header.accept-encoding.4">10.3</a>, <a href="#rfc.xref.header.accept-encoding.5">10.4</a></li>4925 <li>Accept-Language <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.xref.header.accept-language.2">8.1</a>, <a href="#rfc.iref.h. 15"><b>9.14</b></a>, <a href="#rfc.xref.header.accept-language.3">10.3</a></li>4926 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h. 2"><b>9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li>4927 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.h. 16"><b>9.15</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.15</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li>4928 <li>Content-Language <a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.h. 17"><b>9.16</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li>4929 <li>Content-Location <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc. xref.header.content-location.3">9.5</a>, <a href="#rfc.iref.h.18"><b>9.17</b></a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4922 <li>Accept <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">5.5</a>, <a href="#rfc.xref.header.accept.3">8.1</a>, <a href="#rfc.iref.h.2"><b>9.1</b></a>, <a href="#rfc.xref.header.accept.4">10.3</a></li> 4923 <li>Accept-Charset <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.xref.header.accept-charset.2">8.1</a>, <a href="#rfc.iref.h.3"><b>9.2</b></a>, <a href="#rfc.xref.header.accept-charset.3">10.3</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li> 4924 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">5.4</a>, <a href="#rfc.xref.header.accept-encoding.3">8.1</a>, <a href="#rfc.iref.h.4"><b>9.3</b></a>, <a href="#rfc.xref.header.accept-encoding.4">10.3</a>, <a href="#rfc.xref.header.accept-encoding.5">10.4</a></li> 4925 <li>Accept-Language <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.xref.header.accept-language.2">8.1</a>, <a href="#rfc.iref.h.5"><b>9.4</b></a>, <a href="#rfc.xref.header.accept-language.3">10.3</a></li> 4926 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li> 4927 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.h.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.6</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li> 4928 <li>Content-Language <a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li> 4929 <li>Content-Location <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.3">9.13</a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4930 4930 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4931 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.h.1 9"><b>9.18</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li>4932 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h. 3"><b>9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>4933 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.h. 4"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li>4934 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h. 5"><b>9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>4935 <li>Location <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.h. 6"><b>9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>4936 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h. 7"><b>9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>4931 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.h.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li> 4932 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.11"><b>9.10</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li> 4933 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.h.12"><b>9.11</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li> 4934 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.13"><b>9.12</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li> 4935 <li>Location <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.h.14"><b>9.13</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">C</a></li> 4936 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h.15"><b>9.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 4937 4937 <li>MIME-Version <a href="#rfc.xref.mime-version.1">10.3</a>, <a href="#rfc.iref.h.20"><b>A.1</b></a></li> 4938 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h. 8"><b>9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li>4939 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.h. 9"><b>9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>4940 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.1 0"><b>9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>4941 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.xref.header.user-agent.2">8.1</a>, <a href="#rfc.iref.h.1 1"><b>9.10</b></a>, <a href="#rfc.xref.header.user-agent.3">10.3</a>, <a href="#rfc.xref.header.user-agent.4">11.1</a></li>4938 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.16"><b>9.15</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li> 4939 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.h.17"><b>9.16</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li> 4940 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.18"><b>9.17</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">C</a></li> 4941 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.xref.header.user-agent.2">8.1</a>, <a href="#rfc.iref.h.19"><b>9.18</b></a>, <a href="#rfc.xref.header.user-agent.3">10.3</a>, <a href="#rfc.xref.header.user-agent.4">11.1</a></li> 4942 4942 </ul> 4943 4943 </li> … … 4949 4949 </li> 4950 4950 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 4951 <li>Location header field <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.l.1"><b>9. 5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>4951 <li>Location header field <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.l.1"><b>9.13</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">C</a></li> 4952 4952 </ul> 4953 4953 </li> 4954 4954 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 4955 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>9. 6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>4955 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>9.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 4956 4956 <li>Methods 4957 4957 <ul> … … 4960 4960 <li>GET <a href="#rfc.iref.m.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">10.1</a></li> 4961 4961 <li>HEAD <a href="#rfc.iref.m.3"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">10.1</a></li> 4962 <li>OPTIONS <a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">9. 6</a>, <a href="#rfc.xref.OPTIONS.2">10.1</a></li>4962 <li>OPTIONS <a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">9.14</a>, <a href="#rfc.xref.OPTIONS.2">10.1</a></li> 4963 4963 <li>POST <a href="#rfc.iref.m.4"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">10.1</a>, <a href="#rfc.xref.POST.2">C</a></li> 4964 4964 <li>PUT <a href="#rfc.iref.m.5"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">10.1</a>, <a href="#rfc.xref.PUT.2">C</a></li> 4965 <li>TRACE <a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">9. 6</a>, <a href="#rfc.xref.TRACE.2">10.1</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li>4965 <li>TRACE <a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">9.14</a>, <a href="#rfc.xref.TRACE.2">10.1</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li> 4966 4966 </ul> 4967 4967 </li> … … 4970 4970 </li> 4971 4971 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 4972 <li>OPTIONS method <a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">9. 6</a>, <a href="#rfc.xref.OPTIONS.2">10.1</a></li>4972 <li>OPTIONS method <a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">9.14</a>, <a href="#rfc.xref.OPTIONS.2">10.1</a></li> 4973 4973 </ul> 4974 4974 </li> 4975 4975 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4976 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">1.3.2</a>, <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.18">2.2.1</a>, <a href="#rfc.xref.Part1.19">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.7</a>, <a href="#rfc.xref.Part1.22">2.3.8</a>, <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.1</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.33">4.3.2</a>, <a href="#rfc.xref.Part1.34">4.4.4</a>, <a href="#rfc.xref.Part1.35">4.4.6</a>, <a href="#rfc.xref.Part1.36">4.6.15</a>, <a href="#rfc.xref.Part1.37">4.7.6</a>, <a href="#rfc.xref.Part1.38">5.4</a>, <a href="#rfc.xref.Part1.39">5.4</a>, <a href="#rfc.xref.Part1.40">5.4</a>, <a href="#rfc.xref.Part1.41">5.4.1</a>, <a href="#rfc.xref.Part1.42">5.4.1</a>, <a href="#rfc.xref.Part1.43">6.1</a>, <a href="#rfc.xref.Part1.44">6.2</a>, <a href="#rfc.xref.Part1.45">7</a>, <a href="#rfc.xref.Part1.46">7.1</a>, <a href="#rfc.xref.Part1.47">9. 3</a>, <a href="#rfc.xref.Part1.48">9.9</a>, <a href="#rfc.xref.Part1.49">9.9</a>, <a href="#rfc.xref.Part1.50">9.10</a>, <a href="#rfc.xref.Part1.51">9.17</a>, <a href="#rfc.xref.Part1.52">10.4</a>, <a href="#rfc.xref.Part1.53">10.4</a>, <a href="#rfc.xref.Part1.54">10.4</a>, <a href="#rfc.xref.Part1.55">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.56">A.6</a>, <a href="#rfc.xref.Part1.57">C</a><ul>4976 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">1.3.2</a>, <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.18">2.2.1</a>, <a href="#rfc.xref.Part1.19">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.7</a>, <a href="#rfc.xref.Part1.22">2.3.8</a>, <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.1</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.33">4.3.2</a>, <a href="#rfc.xref.Part1.34">4.4.4</a>, <a href="#rfc.xref.Part1.35">4.4.6</a>, <a href="#rfc.xref.Part1.36">4.6.15</a>, <a href="#rfc.xref.Part1.37">4.7.6</a>, <a href="#rfc.xref.Part1.38">5.4</a>, <a href="#rfc.xref.Part1.39">5.4</a>, <a href="#rfc.xref.Part1.40">5.4</a>, <a href="#rfc.xref.Part1.41">5.4.1</a>, <a href="#rfc.xref.Part1.42">5.4.1</a>, <a href="#rfc.xref.Part1.43">6.1</a>, <a href="#rfc.xref.Part1.44">6.2</a>, <a href="#rfc.xref.Part1.45">7</a>, <a href="#rfc.xref.Part1.46">7.1</a>, <a href="#rfc.xref.Part1.47">9.8</a>, <a href="#rfc.xref.Part1.48">9.11</a>, <a href="#rfc.xref.Part1.49">9.17</a>, <a href="#rfc.xref.Part1.50">9.17</a>, <a href="#rfc.xref.Part1.51">9.18</a>, <a href="#rfc.xref.Part1.52">10.4</a>, <a href="#rfc.xref.Part1.53">10.4</a>, <a href="#rfc.xref.Part1.54">10.4</a>, <a href="#rfc.xref.Part1.55">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.56">A.6</a>, <a href="#rfc.xref.Part1.57">C</a><ul> 4977 4977 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.3</a></li> 4978 4978 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> … … 4981 4981 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.16">1.3.2</a></li> 4982 4982 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a></li> 4983 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.4 8">9.9</a>, <a href="#rfc.xref.Part1.50">9.10</a></li>4983 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.49">9.17</a>, <a href="#rfc.xref.Part1.51">9.18</a></li> 4984 4984 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.25">3.1</a></li> 4985 4985 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.24">3.1</a></li> … … 4997 4997 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.19">2.3.1</a>, <a href="#rfc.xref.Part1.22">2.3.8</a></li> 4998 4998 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.29">3.2</a></li> 4999 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.46">7.1</a>, <a href="#rfc.xref.Part1. 51">9.17</a></li>4999 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.46">7.1</a>, <a href="#rfc.xref.Part1.47">9.8</a></li> 5000 5000 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.27">3.1</a></li> 5001 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1. 49">9.9</a>, <a href="#rfc.xref.Part1.57">C</a></li>5002 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.4 7">9.3</a></li>5001 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.50">9.17</a>, <a href="#rfc.xref.Part1.57">C</a></li> 5002 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.48">9.11</a></li> 5003 5003 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.33">4.3.2</a>, <a href="#rfc.xref.Part1.36">4.6.15</a></li> 5004 5004 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.21">2.3.7</a></li> … … 5056 5056 </li> 5057 5057 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 5058 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.2"><b>9. 7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li>5058 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.2"><b>9.15</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li> 5059 5059 <li>representation <a href="#rfc.iref.r.1">7</a></li> 5060 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.3"><b>9. 8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>5060 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.3"><b>9.16</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li> 5061 5061 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">5.1</a>, <a href="#rfc.xref.RFC1123.2">5.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul> 5062 5062 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">5.1</a></li> … … 5090 5090 <li><em>RFC2295</em> <a href="#rfc.xref.RFC2295.1">8</a>, <a href="#RFC2295"><b>13.1</b></a></li> 5091 5091 <li><em>RFC2388</em> <a href="#rfc.xref.RFC2388.1">5.5.2</a>, <a href="#RFC2388"><b>13.2</b></a></li> 5092 <li><em>RFC2557</em> <a href="#rfc.xref.RFC2557.1">9. 17</a>, <a href="#RFC2557"><b>13.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.7</a><ul>5093 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">9. 17</a></li>5092 <li><em>RFC2557</em> <a href="#rfc.xref.RFC2557.1">9.8</a>, <a href="#RFC2557"><b>13.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.7</a><ul> 5093 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">9.8</a></li> 5094 5094 </ul> 5095 5095 </li> 5096 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.5</a>, <a href="#rfc.xref.RFC2616.3">9. 14</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">E.1</a><ul>5096 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.5</a>, <a href="#rfc.xref.RFC2616.3">9.4</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">E.1</a><ul> 5097 5097 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">4.5</a></li> 5098 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616.3">9. 14</a></li>5098 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616.3">9.4</a></li> 5099 5099 </ul> 5100 5100 </li> … … 5108 5108 </ul> 5109 5109 </li> 5110 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">9. 5</a>, <a href="#rfc.xref.RFC3986.2">9.5</a>, <a href="#RFC3986"><b>13.1</b></a><ul>5111 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">9. 5</a></li>5112 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">9. 5</a></li>5110 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">9.13</a>, <a href="#rfc.xref.RFC3986.2">9.13</a>, <a href="#RFC3986"><b>13.1</b></a><ul> 5111 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">9.13</a></li> 5112 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">9.13</a></li> 5113 5113 </ul> 5114 5114 </li> 5115 5115 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">5.5</a>, <a href="#RFC4288"><b>13.1</b></a></li> 5116 <li><em>RFC4647</em> <a href="#rfc.xref.RFC4647.1">9. 14</a>, <a href="#rfc.xref.RFC4647.2">9.14</a>, <a href="#rfc.xref.RFC4647.3">9.14</a>, <a href="#rfc.xref.RFC4647.4">9.14</a>, <a href="#RFC4647"><b>13.1</b></a><ul>5117 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1">9. 14</a></li>5118 <li><em>Section 2.3</em> <a href="#rfc.xref.RFC4647.2">9. 14</a></li>5119 <li><em>Section 3</em> <a href="#rfc.xref.RFC4647.3">9. 14</a></li>5120 <li><em>Section 3.3.1</em> <a href="#rfc.xref.RFC4647.4">9. 14</a></li>5116 <li><em>RFC4647</em> <a href="#rfc.xref.RFC4647.1">9.4</a>, <a href="#rfc.xref.RFC4647.2">9.4</a>, <a href="#rfc.xref.RFC4647.3">9.4</a>, <a href="#rfc.xref.RFC4647.4">9.4</a>, <a href="#RFC4647"><b>13.1</b></a><ul> 5117 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1">9.4</a></li> 5118 <li><em>Section 2.3</em> <a href="#rfc.xref.RFC4647.2">9.4</a></li> 5119 <li><em>Section 3</em> <a href="#rfc.xref.RFC4647.3">9.4</a></li> 5120 <li><em>Section 3.3.1</em> <a href="#rfc.xref.RFC4647.4">9.4</a></li> 5121 5121 </ul> 5122 5122 </li> … … 5129 5129 </ul> 5130 5130 </li> 5131 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">5.1</a>, <a href="#rfc.xref.RFC5322.2">9. 2</a>, <a href="#rfc.xref.RFC5322.3">9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a>, <a href="#RFC5322"><b>13.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul>5131 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">5.1</a>, <a href="#rfc.xref.RFC5322.2">9.10</a>, <a href="#rfc.xref.RFC5322.3">9.12</a>, <a href="#rfc.xref.RFC5322.4">9.12</a>, <a href="#RFC5322"><b>13.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul> 5132 5132 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">5.1</a></li> 5133 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">9. 4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a></li>5134 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">9. 2</a></li>5133 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">9.12</a>, <a href="#rfc.xref.RFC5322.4">9.12</a></li> 5134 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">9.10</a></li> 5135 5135 </ul> 5136 5136 </li> … … 5148 5148 <li>Safe Methods <a href="#rfc.iref.s.2"><b>2.1.1</b></a></li> 5149 5149 <li>selected representation <a href="#rfc.iref.s.1"><b>1.1</b></a></li> 5150 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.39"><b>9. 9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>5150 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.39"><b>9.17</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">C</a></li> 5151 5151 <li>Status Codes 5152 5152 <ul> … … 5192 5192 </li> 5193 5193 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 5194 <li>TRACE method <a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">9. 6</a>, <a href="#rfc.xref.TRACE.2">10.1</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li>5194 <li>TRACE method <a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">9.14</a>, <a href="#rfc.xref.TRACE.2">10.1</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li> 5195 5195 </ul> 5196 5196 </li> 5197 5197 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 5198 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.xref.header.user-agent.2">8.1</a>, <a href="#rfc.iref.u.1"><b>9.1 0</b></a>, <a href="#rfc.xref.header.user-agent.3">10.3</a>, <a href="#rfc.xref.header.user-agent.4">11.1</a></li>5198 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.xref.header.user-agent.2">8.1</a>, <a href="#rfc.iref.u.1"><b>9.18</b></a>, <a href="#rfc.xref.header.user-agent.3">10.3</a>, <a href="#rfc.xref.header.user-agent.4">11.1</a></li> 5199 5199 </ul> 5200 5200 </li> -
draft-ietf-httpbis/experiment/p2-semantics.xml
r1631 r1633 2911 2911 </t> 2912 2912 2913 2914 <section title="Accept" anchor="header.accept"> 2915 <iref primary="true" item="Accept header field" x:for-anchor=""/> 2916 <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/> 2917 <x:anchor-alias value="Accept"/> 2918 <x:anchor-alias value="accept-ext"/> 2919 <x:anchor-alias value="accept-params"/> 2920 <x:anchor-alias value="media-range"/> 2921 <t> 2922 The "Accept" header field can be used by user agents to specify 2923 response media types that are acceptable. Accept header fields can be used to 2924 indicate that the request is specifically limited to a small set of desired 2925 types, as in the case of a request for an in-line image. 2926 </t> 2927 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/> 2928 <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] ) 2929 2930 <x:ref>media-range</x:ref> = ( "*/*" 2931 / ( <x:ref>type</x:ref> "/" "*" ) 2932 / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> ) 2933 ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> ) 2934 <x:ref>accept-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> ) 2935 <x:ref>accept-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ] 2936 </artwork></figure> 2937 <t> 2938 The asterisk "*" character is used to group media types into ranges, 2939 with "*/*" indicating all media types and "type/*" indicating all 2940 subtypes of that type. The media-range &MAY; include media type 2941 parameters that are applicable to that range. 2942 </t> 2943 <t> 2944 Each media-range &MAY; be followed by one or more accept-params, 2945 beginning with the "q" parameter for indicating a relative quality 2946 factor. The first "q" parameter (if any) separates the media-range 2947 parameter(s) from the accept-params. Quality factors allow the user 2948 or user agent to indicate the relative degree of preference for that 2949 media-range, using the qvalue scale from 0 to 1 (qvalue;). The 2950 default value is q=1. 2951 </t> 2952 <x:note> 2953 <t> 2954 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type 2955 parameters from Accept extension parameters is due to historical 2956 practice. Although this prevents any media type parameter named 2957 "q" from being used with a media range, such an event is believed 2958 to be unlikely given the lack of any "q" parameters in the IANA 2959 media type registry and the rare usage of any media type 2960 parameters in Accept. Future media types are discouraged from 2961 registering any parameter named "q". 2962 </t> 2963 </x:note> 2964 <t> 2965 The example 2966 </t> 2967 <figure><artwork type="example"> 2968 Accept: audio/*; q=0.2, audio/basic 2969 </artwork></figure> 2970 <t> 2971 &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio 2972 type if it is the best available after an 80% mark-down in quality". 2973 </t> 2974 <t> 2975 A request without any Accept header field implies that the user agent 2976 will accept any media type in response. 2977 If an Accept header field is present in a request and none of the 2978 available representations for the response have a media type that is 2979 listed as acceptable, the origin server &MAY; either 2980 honor the Accept header field by sending a 406 (Not Acceptable) response 2981 or disregard the Accept header field by treating the response as if 2982 it is not subject to content negotiation. 2983 </t> 2984 <t> 2985 A more elaborate example is 2986 </t> 2987 <figure><artwork type="example"> 2988 Accept: text/plain; q=0.5, text/html, 2989 text/x-dvi; q=0.8, text/x-c 2990 </artwork></figure> 2991 <t> 2992 Verbally, this would be interpreted as "text/html and text/x-c are 2993 the preferred media types, but if they do not exist, then send the 2994 text/x-dvi representation, and if that does not exist, send the text/plain 2995 representation". 2996 </t> 2997 <t> 2998 Media ranges can be overridden by more specific media ranges or 2999 specific media types. If more than one media range applies to a given 3000 type, the most specific reference has precedence. For example, 3001 </t> 3002 <figure><artwork type="example"> 3003 Accept: text/*, text/plain, text/plain;format=flowed, */* 3004 </artwork></figure> 3005 <t> 3006 have the following precedence: 3007 <list style="numbers"> 3008 <t>text/plain;format=flowed</t> 3009 <t>text/plain</t> 3010 <t>text/*</t> 3011 <t>*/*</t> 3012 </list> 3013 </t> 3014 <t> 3015 The media type quality factor associated with a given type is 3016 determined by finding the media range with the highest precedence 3017 which matches that type. For example, 3018 </t> 3019 <figure><artwork type="example"> 3020 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 3021 text/html;level=2;q=0.4, */*;q=0.5 3022 </artwork></figure> 3023 <t> 3024 would cause the following values to be associated: 3025 </t> 3026 <texttable align="left"> 3027 <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol> 3028 <c>text/html;level=1</c> <c>1</c> 3029 <c>text/html</c> <c>0.7</c> 3030 <c>text/plain</c> <c>0.3</c> 3031 <c>image/jpeg</c> <c>0.5</c> 3032 <c>text/html;level=2</c> <c>0.4</c> 3033 <c>text/html;level=3</c> <c>0.7</c> 3034 </texttable> 3035 <t> 3036 <x:h>Note:</x:h> A user agent might be provided with a default set of quality 3037 values for certain media ranges. However, unless the user agent is 3038 a closed system which cannot interact with other rendering agents, 3039 this default set ought to be configurable by the user. 3040 </t> 3041 </section> 3042 3043 <section title="Accept-Charset" anchor="header.accept-charset"> 3044 <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/> 3045 <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/> 3046 <x:anchor-alias value="Accept-Charset"/> 3047 <t> 3048 The "Accept-Charset" header field can be used by user agents to 3049 indicate what character encodings are acceptable in a response 3050 payload. This field allows 3051 clients capable of understanding more comprehensive or special-purpose 3052 character encodings to signal that capability to a server which is capable of 3053 representing documents in those character encodings. 3054 </t> 3055 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/> 3056 <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" ) 3057 [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] ) 3058 </artwork></figure> 3059 <t> 3060 Character encoding values (a.k.a., charsets) are described in 3061 <xref target="character.sets"/>. Each charset &MAY; be given an 3062 associated quality value which represents the user's preference 3063 for that charset. The default value is q=1. An example is 3064 </t> 3065 <figure><artwork type="example"> 3066 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 3067 </artwork></figure> 3068 <t> 3069 The special value "*", if present in the Accept-Charset field, 3070 matches every character encoding which is not mentioned elsewhere in the 3071 Accept-Charset field. If no "*" is present in an Accept-Charset field, then 3072 all character encodings not explicitly mentioned get a quality value of 0. 3073 </t> 3074 <t> 3075 A request without any Accept-Charset header field implies that the user 3076 agent will accept any character encoding in response. 3077 If an Accept-Charset header field is present in a request and none of the 3078 available representations for the response have a character encoding that 3079 is listed as acceptable, the origin server &MAY; either honor the 3080 Accept-Charset header field by sending a 406 (Not Acceptable) response or 3081 disregard the Accept-Charset header field by treating the response as if 3082 it is not subject to content negotiation. 3083 </t> 3084 </section> 3085 3086 <section title="Accept-Encoding" anchor="header.accept-encoding"> 3087 <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/> 3088 <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/> 3089 <x:anchor-alias value="Accept-Encoding"/> 3090 <x:anchor-alias value="codings"/> 3091 <t> 3092 The "Accept-Encoding" header field can be used by user agents to 3093 indicate what response content-codings (<xref target="content.codings"/>) 3094 are acceptable in the response. An "identity" token is used as a synonym 3095 for "no encoding" in order to communicate when no encoding is preferred. 3096 </t> 3097 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/> 3098 <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> ] ) 3099 <x:ref>codings</x:ref> = <x:ref>content-coding</x:ref> / "identity" / "*" 3100 </artwork></figure> 3101 <t> 3102 Each codings value &MAY; be given an associated quality value which 3103 represents the preference for that encoding. The default value is q=1. 3104 </t> 3105 <t> 3106 For example, 3107 </t> 3108 <figure><artwork type="example"> 3109 Accept-Encoding: compress, gzip 3110 Accept-Encoding: 3111 Accept-Encoding: * 3112 Accept-Encoding: compress;q=0.5, gzip;q=1.0 3113 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 3114 </artwork></figure> 3115 <t> 3116 A server tests whether a content-coding for a given representation is 3117 acceptable, according to an Accept-Encoding field, using these rules: 3118 <list style="numbers"> 3119 <t>The special "*" symbol in an Accept-Encoding field matches any 3120 available content-coding not explicitly listed in the header 3121 field.</t> 3122 3123 <t>If the representation has no content-coding, then it is acceptable 3124 by default unless specifically excluded by the Accept-Encoding field 3125 stating either "identity;q=0" or "*;q=0" without a more specific 3126 entry for "identity".</t> 3127 3128 <t>If the representation's content-coding is one of the content-codings 3129 listed in the Accept-Encoding field, then it is acceptable unless 3130 it is accompanied by a qvalue of 0. (As defined in qvalue;, a 3131 qvalue of 0 means "not acceptable".)</t> 3132 3133 <t>If multiple content-codings are acceptable, then the acceptable 3134 content-coding with the highest non-zero qvalue is preferred.</t> 3135 </list> 3136 </t> 3137 <t> 3138 An Accept-Encoding header field with a combined field-value that is empty 3139 implies that the user agent does not want any content-coding in response. 3140 If an Accept-Encoding header field is present in a request and none of the 3141 available representations for the response have a content-coding that 3142 is listed as acceptable, the origin server &SHOULD; send a response 3143 without any content-coding. 3144 </t> 3145 <t> 3146 A request without an Accept-Encoding header field implies that the user 3147 agent will accept any content-coding in response, but a representation 3148 without content-coding is preferred for compatibility with the widest 3149 variety of user agents. 3150 </t> 3151 <x:note> 3152 <t> 3153 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues 3154 associated with content-codings. This means that qvalues will not 3155 work and are not permitted with x-gzip or x-compress. 3156 </t> 3157 </x:note> 3158 </section> 3159 3160 <section title="Accept-Language" anchor="header.accept-language"> 3161 <iref primary="true" item="Accept-Language header field" x:for-anchor=""/> 3162 <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/> 3163 <x:anchor-alias value="Accept-Language"/> 3164 <x:anchor-alias value="language-range"/> 3165 <t> 3166 The "Accept-Language" header field can be used by user agents to 3167 indicate the set of natural languages that are preferred in the response. 3168 Language tags are defined in <xref target="language.tags"/>. 3169 </t> 3170 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/> 3171 <x:ref>Accept-Language</x:ref> = 3172 1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] ) 3173 <x:ref>language-range</x:ref> = 3174 <language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>> 3175 </artwork></figure> 3176 <t> 3177 Each language-range can be given an associated quality value which 3178 represents an estimate of the user's preference for the languages 3179 specified by that range. The quality value defaults to "q=1". For 3180 example, 3181 </t> 3182 <figure><artwork type="example"> 3183 Accept-Language: da, en-gb;q=0.8, en;q=0.7 3184 </artwork></figure> 3185 <t> 3186 would mean: "I prefer Danish, but will accept British English and 3187 other types of English". 3188 (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>) 3189 </t> 3190 <t> 3191 For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines 3192 several matching schemes. Implementations can offer the most appropriate 3193 matching scheme for their requirements. 3194 </t> 3195 <x:note> 3196 <t> 3197 <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647" 3198 x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was 3199 previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>. 3200 </t> 3201 </x:note> 3202 <t> 3203 It might be contrary to the privacy expectations of the user to send 3204 an Accept-Language header field with the complete linguistic preferences of 3205 the user in every request. For a discussion of this issue, see 3206 <xref target="privacy.issues.connected.to.accept.header.fields"/>. 3207 </t> 3208 <t> 3209 As intelligibility is highly dependent on the individual user, it is 3210 recommended that client applications make the choice of linguistic 3211 preference available to the user. If the choice is not made 3212 available, then the Accept-Language header field &MUST-NOT; be given in 3213 the request. 3214 </t> 3215 <x:note> 3216 <t> 3217 <x:h>Note:</x:h> When making the choice of linguistic preference available to 3218 the user, we remind implementors of the fact that users are not 3219 familiar with the details of language matching as described above, 3220 and ought to be provided appropriate guidance. As an example, users 3221 might assume that on selecting "en-gb", they will be served any 3222 kind of English document if British English is not available. A 3223 user agent might suggest in such a case to add "en" to get the 3224 best matching behavior. 3225 </t> 3226 </x:note> 3227 </section> 3228 2913 3229 <section title="Allow" anchor="header.allow"> 2914 3230 <iref primary="true" item="Allow header field" x:for-anchor=""/> … … 2937 3253 understand all the methods specified in order to handle them according to 2938 3254 the generic message handling rules. 3255 </t> 3256 </section> 3257 3258 <section title="Content-Encoding" anchor="header.content-encoding"> 3259 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/> 3260 <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/> 3261 <x:anchor-alias value="Content-Encoding"/> 3262 <t> 3263 The "Content-Encoding" header field indicates what content-codings 3264 have been applied to the representation beyond those inherent in the media 3265 type, and thus what decoding mechanisms have to be applied in order to obtain 3266 the media-type referenced by the Content-Type header field. 3267 Content-Encoding is primarily used to allow a representation to be 3268 compressed without losing the identity of its underlying media type. 3269 </t> 3270 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/> 3271 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref> 3272 </artwork></figure> 3273 <t> 3274 Content codings are defined in <xref target="content.codings"/>. An example of its use is 3275 </t> 3276 <figure><artwork type="example"> 3277 Content-Encoding: gzip 3278 </artwork></figure> 3279 <t> 3280 The content-coding is a characteristic of the representation. 3281 Typically, the representation body is stored with this 3282 encoding and is only decoded before rendering or analogous usage. 3283 However, a transforming proxy &MAY; modify the content-coding if the 3284 new coding is known to be acceptable to the recipient, unless the 3285 "no-transform" cache-control directive is present in the message. 3286 </t> 3287 <t> 3288 If the media type includes an inherent encoding, such as a data format 3289 that is always compressed, then that encoding would not be restated as 3290 a Content-Encoding even if it happens to be the same algorithm as one 3291 of the content-codings. Such a content-coding would only be listed if, 3292 for some bizarre reason, it is applied a second time to form the 3293 representation. Likewise, an origin server might choose to publish the 3294 same payload data as multiple representations that differ only in whether 3295 the coding is defined as part of Content-Type or Content-Encoding, since 3296 some user agents will behave differently in their handling of each 3297 response (e.g., open a "Save as ..." dialog instead of automatic 3298 decompression and rendering of content). 3299 </t> 3300 <t> 3301 A representation that has a content-coding applied to it &MUST; include 3302 a Content-Encoding header field (<xref target="header.content-encoding"/>) 3303 that lists the content-coding(s) applied. 3304 </t> 3305 <t> 3306 If multiple encodings have been applied to a representation, the content 3307 codings &MUST; be listed in the order in which they were applied. 3308 Additional information about the encoding parameters &MAY; be provided 3309 by other header fields not defined by this specification. 3310 </t> 3311 <t> 3312 If the content-coding of a representation in a request message is not 3313 acceptable to the origin server, the server &SHOULD; respond with a 3314 status code of 415 (Unsupported Media Type). 3315 </t> 3316 </section> 3317 3318 <section title="Content-Language" anchor="header.content-language"> 3319 <iref primary="true" item="Content-Language header field" x:for-anchor=""/> 3320 <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/> 3321 <x:anchor-alias value="Content-Language"/> 3322 <t> 3323 The "Content-Language" header field describes the natural 3324 language(s) of the intended audience for the representation. Note that this might 3325 not be equivalent to all the languages used within the representation. 3326 </t> 3327 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/> 3328 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref> 3329 </artwork></figure> 3330 <t> 3331 Language tags are defined in <xref target="language.tags"/>. The primary purpose of 3332 Content-Language is to allow a user to identify and differentiate 3333 representations according to the user's own preferred language. Thus, if the 3334 body content is intended only for a Danish-literate audience, the 3335 appropriate field is 3336 </t> 3337 <figure><artwork type="example"> 3338 Content-Language: da 3339 </artwork></figure> 3340 <t> 3341 If no Content-Language is specified, the default is that the content 3342 is intended for all language audiences. This might mean that the 3343 sender does not consider it to be specific to any natural language, 3344 or that the sender does not know for which language it is intended. 3345 </t> 3346 <t> 3347 Multiple languages &MAY; be listed for content that is intended for 3348 multiple audiences. For example, a rendition of the "Treaty of 3349 Waitangi", presented simultaneously in the original Maori and English 3350 versions, would call for 3351 </t> 3352 <figure><artwork type="example"> 3353 Content-Language: mi, en 3354 </artwork></figure> 3355 <t> 3356 However, just because multiple languages are present within a representation 3357 does not mean that it is intended for multiple linguistic audiences. 3358 An example would be a beginner's language primer, such as "A First 3359 Lesson in Latin", which is clearly intended to be used by an 3360 English-literate audience. In this case, the Content-Language would 3361 properly only include "en". 3362 </t> 3363 <t> 3364 Content-Language &MAY; be applied to any media type — it is not 3365 limited to textual documents. 3366 </t> 3367 </section> 3368 3369 <section title="Content-Location" anchor="header.content-location"> 3370 <iref primary="true" item="Content-Location header field" x:for-anchor=""/> 3371 <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/> 3372 <x:anchor-alias value="Content-Location"/> 3373 <t> 3374 The "Content-Location" header field supplies a URI that can be used 3375 as a specific identifier for the representation in this message. 3376 In other words, if one were to perform a GET on this URI at the time 3377 of this message's generation, then a 200 response would contain the 3378 same representation that is enclosed as payload in this message. 3379 </t> 3380 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/> 3381 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> 3382 </artwork></figure> 3383 <t> 3384 The Content-Location value is not a replacement for the effective 3385 Request URI (&effective-request-uri;). It is representation metadata. 3386 It has the same syntax and semantics as the header field of the same name 3387 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>. 3388 However, its appearance in an HTTP message has some special implications 3389 for HTTP recipients. 3390 </t> 3391 <t> 3392 If Content-Location is included in a response message and its value 3393 is the same as the effective request URI, then the response payload 3394 &SHOULD; be considered a current representation of that resource. 3395 For a GET or HEAD request, this is the same as the default semantics 3396 when no Content-Location is provided by the server. For a state-changing 3397 request like PUT or POST, it implies that the server's response contains 3398 the new representation of that resource, thereby distinguishing it from 3399 representations that might only report about the action (e.g., "It worked!"). 3400 This allows authoring applications to update their local copies without 3401 the need for a subsequent GET request. 3402 </t> 3403 <t> 3404 If Content-Location is included in a response message and its value 3405 differs from the effective request URI, then the origin server is 3406 informing recipients that this representation has its own, presumably 3407 more specific, identifier. For a GET or HEAD request, this is an 3408 indication that the effective request URI identifies a resource that 3409 is subject to content negotiation and the selected representation for 3410 this response can also be found at the identified URI. For other 3411 methods, such a Content-Location indicates that this representation 3412 contains a report on the action's status and the same report is 3413 available (for future access with GET) at the given URI. For 3414 example, a purchase transaction made via a POST request might 3415 include a receipt document as the payload of the 200 response; 3416 the Content-Location value provides an identifier for retrieving 3417 a copy of that same receipt in the future. 3418 </t> 3419 <t> 3420 If Content-Location is included in a request message, then it &MAY; 3421 be interpreted by the origin server as an indication of where the 3422 user agent originally obtained the content of the enclosed 3423 representation (prior to any subsequent modification of the content 3424 by that user agent). In other words, the user agent is providing 3425 the same representation metadata that it received with the original 3426 representation. However, such interpretation &MUST-NOT; be used to 3427 alter the semantics of the method requested by the client. For 3428 example, if a client makes a PUT request on a negotiated resource 3429 and the origin server accepts that PUT (without redirection), then the 3430 new set of values for that resource is expected to be consistent with 3431 the one representation supplied in that PUT; the Content-Location 3432 cannot be used as a form of reverse content selection that 3433 identifies only one of the negotiated representations to be updated. 3434 If the user agent had wanted the latter semantics, it would have applied 3435 the PUT directly to the Content-Location URI. 3436 </t> 3437 <t> 3438 A Content-Location field received in a request message is transitory 3439 information that &SHOULD-NOT; be saved with other representation 3440 metadata for use in later responses. The Content-Location's value 3441 might be saved for use in other contexts, such as within source links 3442 or other metadata. 3443 </t> 3444 <t> 3445 A cache cannot assume that a representation with a Content-Location 3446 different from the URI used to retrieve it can be used to respond to 3447 later requests on that Content-Location URI. 3448 </t> 3449 <t> 3450 If the Content-Location value is a partial URI, the partial URI is 3451 interpreted relative to the effective request URI. 3452 </t> 3453 </section> 3454 3455 <section title="Content-Type" anchor="header.content-type"> 3456 <iref primary="true" item="Content-Type header field" x:for-anchor=""/> 3457 <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/> 3458 <x:anchor-alias value="Content-Type"/> 3459 <t> 3460 The "Content-Type" header field indicates the media type of the 3461 representation. In the case of responses to the HEAD method, the media type is 3462 that which would have been sent had the request been a GET. 3463 </t> 3464 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/> 3465 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref> 3466 </artwork></figure> 3467 <t> 3468 Media types are defined in <xref target="media.types"/>. An example of the field is 3469 </t> 3470 <figure><artwork type="example"> 3471 Content-Type: text/html; charset=ISO-8859-4 3472 </artwork></figure> 3473 <t> 3474 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 2939 3475 </t> 2940 3476 </section> … … 3363 3899 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 3364 3900 </artwork></figure> 3365 </section>3366 3367 3368 <section title="Accept" anchor="header.accept">3369 <iref primary="true" item="Accept header field" x:for-anchor=""/>3370 <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>3371 <x:anchor-alias value="Accept"/>3372 <x:anchor-alias value="accept-ext"/>3373 <x:anchor-alias value="accept-params"/>3374 <x:anchor-alias value="media-range"/>3375 <t>3376 The "Accept" header field can be used by user agents to specify3377 response media types that are acceptable. Accept header fields can be used to3378 indicate that the request is specifically limited to a small set of desired3379 types, as in the case of a request for an in-line image.3380 </t>3381 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>3382 <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )3383 3384 <x:ref>media-range</x:ref> = ( "*/*"3385 / ( <x:ref>type</x:ref> "/" "*" )3386 / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )3387 ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )3388 <x:ref>accept-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> )3389 <x:ref>accept-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]3390 </artwork></figure>3391 <t>3392 The asterisk "*" character is used to group media types into ranges,3393 with "*/*" indicating all media types and "type/*" indicating all3394 subtypes of that type. The media-range &MAY; include media type3395 parameters that are applicable to that range.3396 </t>3397 <t>3398 Each media-range &MAY; be followed by one or more accept-params,3399 beginning with the "q" parameter for indicating a relative quality3400 factor. The first "q" parameter (if any) separates the media-range3401 parameter(s) from the accept-params. Quality factors allow the user3402 or user agent to indicate the relative degree of preference for that3403 media-range, using the qvalue scale from 0 to 1 (qvalue;). The3404 default value is q=1.3405 </t>3406 <x:note>3407 <t>3408 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type3409 parameters from Accept extension parameters is due to historical3410 practice. Although this prevents any media type parameter named3411 "q" from being used with a media range, such an event is believed3412 to be unlikely given the lack of any "q" parameters in the IANA3413 media type registry and the rare usage of any media type3414 parameters in Accept. Future media types are discouraged from3415 registering any parameter named "q".3416 </t>3417 </x:note>3418 <t>3419 The example3420 </t>3421 <figure><artwork type="example">3422 Accept: audio/*; q=0.2, audio/basic3423 </artwork></figure>3424 <t>3425 &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio3426 type if it is the best available after an 80% mark-down in quality".3427 </t>3428 <t>3429 A request without any Accept header field implies that the user agent3430 will accept any media type in response.3431 If an Accept header field is present in a request and none of the3432 available representations for the response have a media type that is3433 listed as acceptable, the origin server &MAY; either3434 honor the Accept header field by sending a 406 (Not Acceptable) response3435 or disregard the Accept header field by treating the response as if3436 it is not subject to content negotiation.3437 </t>3438 <t>3439 A more elaborate example is3440 </t>3441 <figure><artwork type="example">3442 Accept: text/plain; q=0.5, text/html,3443 text/x-dvi; q=0.8, text/x-c3444 </artwork></figure>3445 <t>3446 Verbally, this would be interpreted as "text/html and text/x-c are3447 the preferred media types, but if they do not exist, then send the3448 text/x-dvi representation, and if that does not exist, send the text/plain3449 representation".3450 </t>3451 <t>3452 Media ranges can be overridden by more specific media ranges or3453 specific media types. If more than one media range applies to a given3454 type, the most specific reference has precedence. For example,3455 </t>3456 <figure><artwork type="example">3457 Accept: text/*, text/plain, text/plain;format=flowed, */*3458 </artwork></figure>3459 <t>3460 have the following precedence:3461 <list style="numbers">3462 <t>text/plain;format=flowed</t>3463 <t>text/plain</t>3464 <t>text/*</t>3465 <t>*/*</t>3466 </list>3467 </t>3468 <t>3469 The media type quality factor associated with a given type is3470 determined by finding the media range with the highest precedence3471 which matches that type. For example,3472 </t>3473 <figure><artwork type="example">3474 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,3475 text/html;level=2;q=0.4, */*;q=0.53476 </artwork></figure>3477 <t>3478 would cause the following values to be associated:3479 </t>3480 <texttable align="left">3481 <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>3482 <c>text/html;level=1</c> <c>1</c>3483 <c>text/html</c> <c>0.7</c>3484 <c>text/plain</c> <c>0.3</c>3485 <c>image/jpeg</c> <c>0.5</c>3486 <c>text/html;level=2</c> <c>0.4</c>3487 <c>text/html;level=3</c> <c>0.7</c>3488 </texttable>3489 <t>3490 <x:h>Note:</x:h> A user agent might be provided with a default set of quality3491 values for certain media ranges. However, unless the user agent is3492 a closed system which cannot interact with other rendering agents,3493 this default set ought to be configurable by the user.3494 </t>3495 </section>3496 3497 <section title="Accept-Charset" anchor="header.accept-charset">3498 <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>3499 <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>3500 <x:anchor-alias value="Accept-Charset"/>3501 <t>3502 The "Accept-Charset" header field can be used by user agents to3503 indicate what character encodings are acceptable in a response3504 payload. This field allows3505 clients capable of understanding more comprehensive or special-purpose3506 character encodings to signal that capability to a server which is capable of3507 representing documents in those character encodings.3508 </t>3509 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>3510 <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" )3511 [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )3512 </artwork></figure>3513 <t>3514 Character encoding values (a.k.a., charsets) are described in3515 <xref target="character.sets"/>. Each charset &MAY; be given an3516 associated quality value which represents the user's preference3517 for that charset. The default value is q=1. An example is3518 </t>3519 <figure><artwork type="example">3520 Accept-Charset: iso-8859-5, unicode-1-1;q=0.83521 </artwork></figure>3522 <t>3523 The special value "*", if present in the Accept-Charset field,3524 matches every character encoding which is not mentioned elsewhere in the3525 Accept-Charset field. If no "*" is present in an Accept-Charset field, then3526 all character encodings not explicitly mentioned get a quality value of 0.3527 </t>3528 <t>3529 A request without any Accept-Charset header field implies that the user3530 agent will accept any character encoding in response.3531 If an Accept-Charset header field is present in a request and none of the3532 available representations for the response have a character encoding that3533 is listed as acceptable, the origin server &MAY; either honor the3534 Accept-Charset header field by sending a 406 (Not Acceptable) response or3535 disregard the Accept-Charset header field by treating the response as if3536 it is not subject to content negotiation.3537 </t>3538 </section>3539 3540 <section title="Accept-Encoding" anchor="header.accept-encoding">3541 <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>3542 <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>3543 <x:anchor-alias value="Accept-Encoding"/>3544 <x:anchor-alias value="codings"/>3545 <t>3546 The "Accept-Encoding" header field can be used by user agents to3547 indicate what response content-codings (<xref target="content.codings"/>)3548 are acceptable in the response. An "identity" token is used as a synonym3549 for "no encoding" in order to communicate when no encoding is preferred.3550 </t>3551 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>3552 <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> ] )3553 <x:ref>codings</x:ref> = <x:ref>content-coding</x:ref> / "identity" / "*"3554 </artwork></figure>3555 <t>3556 Each codings value &MAY; be given an associated quality value which3557 represents the preference for that encoding. The default value is q=1.3558 </t>3559 <t>3560 For example,3561 </t>3562 <figure><artwork type="example">3563 Accept-Encoding: compress, gzip3564 Accept-Encoding:3565 Accept-Encoding: *3566 Accept-Encoding: compress;q=0.5, gzip;q=1.03567 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=03568 </artwork></figure>3569 <t>3570 A server tests whether a content-coding for a given representation is3571 acceptable, according to an Accept-Encoding field, using these rules:3572 <list style="numbers">3573 <t>The special "*" symbol in an Accept-Encoding field matches any3574 available content-coding not explicitly listed in the header3575 field.</t>3576 3577 <t>If the representation has no content-coding, then it is acceptable3578 by default unless specifically excluded by the Accept-Encoding field3579 stating either "identity;q=0" or "*;q=0" without a more specific3580 entry for "identity".</t>3581 3582 <t>If the representation's content-coding is one of the content-codings3583 listed in the Accept-Encoding field, then it is acceptable unless3584 it is accompanied by a qvalue of 0. (As defined in qvalue;, a3585 qvalue of 0 means "not acceptable".)</t>3586 3587 <t>If multiple content-codings are acceptable, then the acceptable3588 content-coding with the highest non-zero qvalue is preferred.</t>3589 </list>3590 </t>3591 <t>3592 An Accept-Encoding header field with a combined field-value that is empty3593 implies that the user agent does not want any content-coding in response.3594 If an Accept-Encoding header field is present in a request and none of the3595 available representations for the response have a content-coding that3596 is listed as acceptable, the origin server &SHOULD; send a response3597 without any content-coding.3598 </t>3599 <t>3600 A request without an Accept-Encoding header field implies that the user3601 agent will accept any content-coding in response, but a representation3602 without content-coding is preferred for compatibility with the widest3603 variety of user agents.3604 </t>3605 <x:note>3606 <t>3607 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues3608 associated with content-codings. This means that qvalues will not3609 work and are not permitted with x-gzip or x-compress.3610 </t>3611 </x:note>3612 </section>3613 3614 <section title="Accept-Language" anchor="header.accept-language">3615 <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>3616 <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>3617 <x:anchor-alias value="Accept-Language"/>3618 <x:anchor-alias value="language-range"/>3619 <t>3620 The "Accept-Language" header field can be used by user agents to3621 indicate the set of natural languages that are preferred in the response.3622 Language tags are defined in <xref target="language.tags"/>.3623 </t>3624 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>3625 <x:ref>Accept-Language</x:ref> =3626 1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )3627 <x:ref>language-range</x:ref> =3628 <language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>>3629 </artwork></figure>3630 <t>3631 Each language-range can be given an associated quality value which3632 represents an estimate of the user's preference for the languages3633 specified by that range. The quality value defaults to "q=1". For3634 example,3635 </t>3636 <figure><artwork type="example">3637 Accept-Language: da, en-gb;q=0.8, en;q=0.73638 </artwork></figure>3639 <t>3640 would mean: "I prefer Danish, but will accept British English and3641 other types of English".3642 (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)3643 </t>3644 <t>3645 For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines3646 several matching schemes. Implementations can offer the most appropriate3647 matching scheme for their requirements.3648 </t>3649 <x:note>3650 <t>3651 <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647"3652 x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was3653 previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.3654 </t>3655 </x:note>3656 <t>3657 It might be contrary to the privacy expectations of the user to send3658 an Accept-Language header field with the complete linguistic preferences of3659 the user in every request. For a discussion of this issue, see3660 <xref target="privacy.issues.connected.to.accept.header.fields"/>.3661 </t>3662 <t>3663 As intelligibility is highly dependent on the individual user, it is3664 recommended that client applications make the choice of linguistic3665 preference available to the user. If the choice is not made3666 available, then the Accept-Language header field &MUST-NOT; be given in3667 the request.3668 </t>3669 <x:note>3670 <t>3671 <x:h>Note:</x:h> When making the choice of linguistic preference available to3672 the user, we remind implementors of the fact that users are not3673 familiar with the details of language matching as described above,3674 and ought to be provided appropriate guidance. As an example, users3675 might assume that on selecting "en-gb", they will be served any3676 kind of English document if British English is not available. A3677 user agent might suggest in such a case to add "en" to get the3678 best matching behavior.3679 </t>3680 </x:note>3681 </section>3682 3683 <section title="Content-Encoding" anchor="header.content-encoding">3684 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>3685 <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>3686 <x:anchor-alias value="Content-Encoding"/>3687 <t>3688 The "Content-Encoding" header field indicates what content-codings3689 have been applied to the representation beyond those inherent in the media3690 type, and thus what decoding mechanisms have to be applied in order to obtain3691 the media-type referenced by the Content-Type header field.3692 Content-Encoding is primarily used to allow a representation to be3693 compressed without losing the identity of its underlying media type.3694 </t>3695 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>3696 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>3697 </artwork></figure>3698 <t>3699 Content codings are defined in <xref target="content.codings"/>. An example of its use is3700 </t>3701 <figure><artwork type="example">3702 Content-Encoding: gzip3703 </artwork></figure>3704 <t>3705 The content-coding is a characteristic of the representation.3706 Typically, the representation body is stored with this3707 encoding and is only decoded before rendering or analogous usage.3708 However, a transforming proxy &MAY; modify the content-coding if the3709 new coding is known to be acceptable to the recipient, unless the3710 "no-transform" cache-control directive is present in the message.3711 </t>3712 <t>3713 If the media type includes an inherent encoding, such as a data format3714 that is always compressed, then that encoding would not be restated as3715 a Content-Encoding even if it happens to be the same algorithm as one3716 of the content-codings. Such a content-coding would only be listed if,3717 for some bizarre reason, it is applied a second time to form the3718 representation. Likewise, an origin server might choose to publish the3719 same payload data as multiple representations that differ only in whether3720 the coding is defined as part of Content-Type or Content-Encoding, since3721 some user agents will behave differently in their handling of each3722 response (e.g., open a "Save as ..." dialog instead of automatic3723 decompression and rendering of content).3724 </t>3725 <t>3726 A representation that has a content-coding applied to it &MUST; include3727 a Content-Encoding header field (<xref target="header.content-encoding"/>)3728 that lists the content-coding(s) applied.3729 </t>3730 <t>3731 If multiple encodings have been applied to a representation, the content3732 codings &MUST; be listed in the order in which they were applied.3733 Additional information about the encoding parameters &MAY; be provided3734 by other header fields not defined by this specification.3735 </t>3736 <t>3737 If the content-coding of a representation in a request message is not3738 acceptable to the origin server, the server &SHOULD; respond with a3739 status code of 415 (Unsupported Media Type).3740 </t>3741 </section>3742 3743 <section title="Content-Language" anchor="header.content-language">3744 <iref primary="true" item="Content-Language header field" x:for-anchor=""/>3745 <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>3746 <x:anchor-alias value="Content-Language"/>3747 <t>3748 The "Content-Language" header field describes the natural3749 language(s) of the intended audience for the representation. Note that this might3750 not be equivalent to all the languages used within the representation.3751 </t>3752 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>3753 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>3754 </artwork></figure>3755 <t>3756 Language tags are defined in <xref target="language.tags"/>. The primary purpose of3757 Content-Language is to allow a user to identify and differentiate3758 representations according to the user's own preferred language. Thus, if the3759 body content is intended only for a Danish-literate audience, the3760 appropriate field is3761 </t>3762 <figure><artwork type="example">3763 Content-Language: da3764 </artwork></figure>3765 <t>3766 If no Content-Language is specified, the default is that the content3767 is intended for all language audiences. This might mean that the3768 sender does not consider it to be specific to any natural language,3769 or that the sender does not know for which language it is intended.3770 </t>3771 <t>3772 Multiple languages &MAY; be listed for content that is intended for3773 multiple audiences. For example, a rendition of the "Treaty of3774 Waitangi", presented simultaneously in the original Maori and English3775 versions, would call for3776 </t>3777 <figure><artwork type="example">3778 Content-Language: mi, en3779 </artwork></figure>3780 <t>3781 However, just because multiple languages are present within a representation3782 does not mean that it is intended for multiple linguistic audiences.3783 An example would be a beginner's language primer, such as "A First3784 Lesson in Latin", which is clearly intended to be used by an3785 English-literate audience. In this case, the Content-Language would3786 properly only include "en".3787 </t>3788 <t>3789 Content-Language &MAY; be applied to any media type — it is not3790 limited to textual documents.3791 </t>3792 </section>3793 3794 <section title="Content-Location" anchor="header.content-location">3795 <iref primary="true" item="Content-Location header field" x:for-anchor=""/>3796 <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>3797 <x:anchor-alias value="Content-Location"/>3798 <t>3799 The "Content-Location" header field supplies a URI that can be used3800 as a specific identifier for the representation in this message.3801 In other words, if one were to perform a GET on this URI at the time3802 of this message's generation, then a 200 response would contain the3803 same representation that is enclosed as payload in this message.3804 </t>3805 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>3806 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>3807 </artwork></figure>3808 <t>3809 The Content-Location value is not a replacement for the effective3810 Request URI (&effective-request-uri;). It is representation metadata.3811 It has the same syntax and semantics as the header field of the same name3812 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.3813 However, its appearance in an HTTP message has some special implications3814 for HTTP recipients.3815 </t>3816 <t>3817 If Content-Location is included in a response message and its value3818 is the same as the effective request URI, then the response payload3819 &SHOULD; be considered a current representation of that resource.3820 For a GET or HEAD request, this is the same as the default semantics3821 when no Content-Location is provided by the server. For a state-changing3822 request like PUT or POST, it implies that the server's response contains3823 the new representation of that resource, thereby distinguishing it from3824 representations that might only report about the action (e.g., "It worked!").3825 This allows authoring applications to update their local copies without3826 the need for a subsequent GET request.3827 </t>3828 <t>3829 If Content-Location is included in a response message and its value3830 differs from the effective request URI, then the origin server is3831 informing recipients that this representation has its own, presumably3832 more specific, identifier. For a GET or HEAD request, this is an3833 indication that the effective request URI identifies a resource that3834 is subject to content negotiation and the selected representation for3835 this response can also be found at the identified URI. For other3836 methods, such a Content-Location indicates that this representation3837 contains a report on the action's status and the same report is3838 available (for future access with GET) at the given URI. For3839 example, a purchase transaction made via a POST request might3840 include a receipt document as the payload of the 200 response;3841 the Content-Location value provides an identifier for retrieving3842 a copy of that same receipt in the future.3843 </t>3844 <t>3845 If Content-Location is included in a request message, then it &MAY;3846 be interpreted by the origin server as an indication of where the3847 user agent originally obtained the content of the enclosed3848 representation (prior to any subsequent modification of the content3849 by that user agent). In other words, the user agent is providing3850 the same representation metadata that it received with the original3851 representation. However, such interpretation &MUST-NOT; be used to3852 alter the semantics of the method requested by the client. For3853 example, if a client makes a PUT request on a negotiated resource3854 and the origin server accepts that PUT (without redirection), then the3855 new set of values for that resource is expected to be consistent with3856 the one representation supplied in that PUT; the Content-Location3857 cannot be used as a form of reverse content selection that3858 identifies only one of the negotiated representations to be updated.3859 If the user agent had wanted the latter semantics, it would have applied3860 the PUT directly to the Content-Location URI.3861 </t>3862 <t>3863 A Content-Location field received in a request message is transitory3864 information that &SHOULD-NOT; be saved with other representation3865 metadata for use in later responses. The Content-Location's value3866 might be saved for use in other contexts, such as within source links3867 or other metadata.3868 </t>3869 <t>3870 A cache cannot assume that a representation with a Content-Location3871 different from the URI used to retrieve it can be used to respond to3872 later requests on that Content-Location URI.3873 </t>3874 <t>3875 If the Content-Location value is a partial URI, the partial URI is3876 interpreted relative to the effective request URI.3877 </t>3878 </section>3879 3880 <section title="Content-Type" anchor="header.content-type">3881 <iref primary="true" item="Content-Type header field" x:for-anchor=""/>3882 <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>3883 <x:anchor-alias value="Content-Type"/>3884 <t>3885 The "Content-Type" header field indicates the media type of the3886 representation. In the case of responses to the HEAD method, the media type is3887 that which would have been sent had the request been a GET.3888 </t>3889 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>3890 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>3891 </artwork></figure>3892 <t>3893 Media types are defined in <xref target="media.types"/>. An example of the field is3894 </t>3895 <figure><artwork type="example">3896 Content-Type: text/html; charset=ISO-8859-43897 </artwork></figure>3898 <t>3899 Further discussion of Content-Type is provided in <xref target="representation.data"/>.3900 </t>3901 3901 </section> 3902 3902 -
draft-ietf-httpbis/experiment/p4-conditional.html
r1631 r1633 896 896 </div> 897 897 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9. 13</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>):898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>): 899 899 </p> 900 900 <div id="rfc.figure.u.6"></div> … … 1123 1123 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1124 1124 </p> 1125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9. 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 2001125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200 1126 1126 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires, 1127 1127 or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. … … 1318 1318 <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag 1319 1319 1320 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 6.1>1320 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 5.1> 1321 1321 1322 1322 <a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS … … 1426 1426 <li><em>Section 5.1</em> <a href="#rfc.xref.Part2.2">1.2</a></li> 1427 1427 <li><em>Section 8</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1428 <li><em>Section 9. 2</em> <a href="#rfc.xref.Part2.5">4.1</a></li>1429 <li><em>Section 9.1 3</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li>1428 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li> 1429 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.5">4.1</a></li> 1430 1430 </ul> 1431 1431 </li> -
draft-ietf-httpbis/experiment/p4-conditional.xml
r1630 r1633 1368 1368 <x:ref>ETag</x:ref> = entity-tag 1369 1369 1370 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 6.1>1370 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 5.1> 1371 1371 1372 1372 <x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
Note: See TracChangeset
for help on using the changeset viewer.