Changeset 966
- Timestamp:
- 30/07/10 06:12:22 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r963 r966 858 858 <div id="rfc.figure.u.12"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>> 859 859 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>> 860 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>> 861 <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>> 860 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>> 862 861 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>> 863 862 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>> … … 877 876 <div id="rfc.iref.u.1"></div> 878 877 <div id="rfc.iref.o.1"></div> 878 <div id="rfc.iref.b.1"></div> 879 <div id="rfc.iref.s.2"></div> 879 880 <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The 880 881 same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the 881 882 program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server" 882 to refer to the program that can originate authoritative responses to a request. 883 to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term 884 "sender" to refer to whichever component sent a given message and the term "recipient" to refer to any component that receives 885 the message. 883 886 </p> 884 887 <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In … … 919 922 920 923 <span id="exbody">Hello World! 921 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 924 </span></pre><div id="rfc.iref.i.1"></div> 925 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 922 926 <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three 923 927 common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, … … 934 938 at the same time that it is handling A's request. 935 939 </p> 936 <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i. 1"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:940 <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message: 937 941 all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions 938 942 in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent. … … 946 950 <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates 947 951 the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP 948 services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested952 services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target 949 953 resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the 950 954 client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection. … … 1153 1157 might introduce security flaws due to the differing ways that such parsers interpret invalid characters. 1154 1158 </p> 1159 <p id="rfc.section.3.1.p.4">HTTP allows the set of defined header fields to be extended without changing the protocol version (see <a href="#header.field.registration" title="Header Field Registration">Section 10.1</a>). However, such fields might not be recognized by a downstream recipient and might be stripped by non-transparent intermediaries. 1160 Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by transparent proxies and <em class="bcp14">SHOULD</em> be ignored by a recipient. 1161 </p> 1155 1162 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> 1156 1163 <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field … … 1305 1312 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a> 1306 1313 / <a href="#abnf.dependencies" class="smpl">Warning</a> ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> 1307 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a> ; <a href="#Part3" id="rfc.xref.Part3. 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>1314 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a> ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a> 1308 1315 </pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new 1309 1316 or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize 1310 them to be general-header fields. Unrecognized header fields are treated as entity-header fields.1317 them to be general-header fields. 1311 1318 </p> 1312 1319 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="request" href="#request">Request</a></h1> … … 1315 1322 </p> 1316 1323 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a> 1317 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1318 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a> 1319 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> 1324 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1320 1325 <a href="#core.rules" class="smpl">CRLF</a> 1321 1326 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1347 1352 </pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1348 1353 </p> 1349 <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1354 <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1350 1355 </p> 1351 1356 <p id="rfc.section.4.1.2.p.10">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the … … 1379 1384 </div> 1380 1385 <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1381 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1386 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1382 1387 </p> 1383 1388 <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. … … 1409 1414 </p> 1410 1415 <div id="rfc.iref.e.1"></div> 1416 <div id="rfc.iref.t.2"></div> 1411 1417 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1412 <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the resource they are intended for; instead, the value needs to be inferred from the request-target, Host header and 1413 other context. The result of this process is the "Effective Request URI". 1414 </p> 1415 <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the Effective Request URI is the request-target.</p> 1416 <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective 1417 Request URI is constructed by concatenating 1418 <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection 1419 context. The result of this process is called the "effective request URI". The "target resource" is the resource identified 1420 by the effective request URI. 1421 </p> 1422 <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> 1423 <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the effective 1424 request URI is constructed by concatenating 1418 1425 </p> 1419 1426 <p id="rfc.section.4.3.p.4"> </p> … … 1429 1436 <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p> 1430 1437 <div id="rfc.figure.u.40"></div> 1431 <p>Example 1: the Effective Request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.11438 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1432 1439 Host: www.example.org:8080 1433 1440 </pre> <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus … … 1435 1442 </p> 1436 1443 <div id="rfc.figure.u.41"></div> 1437 <p>Example 2: the Effective Request URI for the message</p> <pre class="text">GET * HTTP/1.11444 <p>Example 2: the effective request URI for the message</p> <pre class="text">GET * HTTP/1.1 1438 1445 Host: www.example.org 1439 1446 </pre> <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", 1440 1447 thus "https://www.example.org". 1441 1448 </p> 1442 <p id="rfc.section.4.3.p.8">Effective Request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".1449 <p id="rfc.section.4.3.p.8">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1443 1450 </p> 1444 1451 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1445 1452 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1446 1453 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a> 1447 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1448 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a> 1449 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> 1454 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1450 1455 <a href="#core.rules" class="smpl">CRLF</a> 1451 1456 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1458 1463 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1459 1464 <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1460 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1465 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1461 1466 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1462 1467 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. … … 1588 1593 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3> 1589 1594 <p id="rfc.section.6.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size 1590 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information1591 necessaryfor the recipient to verify that it has received the full message.1595 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary 1596 for the recipient to verify that it has received the full message. 1592 1597 </p> 1593 1598 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> … … 1606 1611 <a href="#chunked.encoding" class="smpl">chunk-ext-val</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#chunked.encoding" class="smpl">quoted-str-nf</a> 1607 1612 <a href="#chunked.encoding" class="smpl">chunk-data</a> = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets 1608 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( <a href="# abnf.dependencies" class="smpl">entity-header</a> <a href="#core.rules" class="smpl">CRLF</a> )1613 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1609 1614 1610 1615 <a href="#chunked.encoding" class="smpl">quoted-str-nf</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#chunked.encoding" class="smpl">qdtext-nf</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> … … 1695 1700 <li>Pointer to specification text</li> 1696 1701 </ul> 1697 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3. 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>).1702 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>). 1698 1703 </p> 1699 1704 <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 1714 1719 </p> 1715 1720 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 1716 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1721 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1717 1722 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1718 1723 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1778 1783 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1779 1784 </p> 1780 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1785 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1781 1786 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 1782 1787 </p> … … 1846 1851 </p> 1847 1852 </div> 1848 <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>).1853 <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1849 1854 </p> 1850 1855 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 1862 1867 </p> 1863 1868 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1864 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1869 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1865 1870 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1866 1871 </p> … … 1889 1894 </p> 1890 1895 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1891 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2. 10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1896 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1892 1897 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1893 1898 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking … … 1896 1901 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1897 1902 <ul> 1898 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2. 11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1899 </li> 1900 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1903 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1904 </li> 1905 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 1901 1906 </li> 1902 1907 </ul> … … 1942 1947 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 1943 1948 an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding 1944 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1949 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1945 1950 </li> 1946 1951 </ul> … … 1988 1993 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 1989 1994 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p> 1990 <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1991 receives the message.1992 </p>1993 1995 <div id="rfc.iref.c.11"></div> 1994 1996 <div id="rfc.iref.h.6"></div> … … 2101 2103 <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host. 2102 2104 </p> 2103 <div id="rfc.iref.t. 2"></div>2105 <div id="rfc.iref.t.3"></div> 2104 2106 <div id="rfc.iref.h.11"></div> 2105 2107 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.te" href="#header.te">TE</a></h2> … … 2150 2152 is always acceptable. 2151 2153 </p> 2152 <div id="rfc.iref.t. 3"></div>2154 <div id="rfc.iref.t.4"></div> 2153 2155 <div id="rfc.iref.h.12"></div> 2154 2156 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> … … 2170 2172 <li>Trailer</li> 2171 2173 </ul> 2172 <div id="rfc.iref.t. 4"></div>2174 <div id="rfc.iref.t.5"></div> 2173 2175 <div id="rfc.iref.h.13"></div> 2174 2176 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2175 2177 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body. 2176 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3. 10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings2178 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 2177 2179 are not. 2178 2180 </p> … … 2183 2185 </p> 2184 2186 <div id="rfc.figure.u.71"></div><pre class="text"> Transfer-Encoding: chunked 2185 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-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 entity-header fields not defined by this specification.2187 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-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. 2186 2188 </p> 2187 2189 <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p> … … 2866 2868 </p> 2867 2869 <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that 2868 not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3. 11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2870 not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2869 2871 </p> 2870 2872 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 3008 3010 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP ) 3009 3011 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( WSP / VCHAR / obs-text ) 3010 <a href="#request" class="smpl">Request</a> = Request-Line *( ( general-header / request-header / 3011 entity-header ) CRLF ) CRLF [ message-body ] 3012 <a href="#request" class="smpl">Request</a> = Request-Line *( header-field CRLF ) CRLF [ message-body ] 3012 3013 <a href="#request-line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF 3013 <a href="#response" class="smpl">Response</a> = Status-Line *( ( general-header / response-header / 3014 entity-header ) CRLF ) CRLF [ message-body ] 3014 <a href="#response" class="smpl">Response</a> = Status-Line *( header-field CRLF ) CRLF [ message-body ] 3015 3015 3016 3016 <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3DIGIT … … 3073 3073 / %x53.75.6E.64.61.79 ; Sunday 3074 3074 3075 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in [Part3], Section 3.1>3076 3077 3075 <a href="#header.fields" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text ) 3078 3076 <a href="#header.fields" class="smpl">field-name</a> = token … … 3153 3151 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second 3154 3152 <a href="#rule.token.separators" class="smpl">token</a> = 1*tchar 3155 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( entity-headerCRLF )3153 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF ) 3156 3154 <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / "compress" / "deflate" / "gzip" / 3157 3155 transfer-extension … … 3440 3438 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length headers" 3441 3439 </li> 3440 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>>: "Clarify entity / representation / variant terminology" 3441 </li> 3442 3442 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "consider removing the 'changes from 2068' sections" 3443 3443 </li> … … 3459 3459 <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind"> 3460 3460 <li class="indline1"><em>BCP97</em> <a class="iref" href="#rfc.xref.BCP97.1">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">13.1</a>, <a class="iref" href="#BCP97"><b>13.2</b></a></li> 3461 <li class="indline1">browser <a class="iref" href="#rfc.iref.b.1"><b>2.1</b></a></li> 3461 3462 </ul> 3462 3463 </li> 3463 3464 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 3464 <li class="indline1">cache <a class="iref" href="#rfc.iref.c.3"> 2.3</a></li>3465 <li class="indline1">cacheable <a class="iref" href="#rfc.iref.c.4"> 2.3</a></li>3465 <li class="indline1">cache <a class="iref" href="#rfc.iref.c.3"><b>2.3</b></a></li> 3466 <li class="indline1">cacheable <a class="iref" href="#rfc.iref.c.4"><b>2.3</b></a></li> 3466 3467 <li class="indline1">chunked (Coding Format) <a class="iref" href="#rfc.iref.c.5">6.2.1</a></li> 3467 <li class="indline1">client <a class="iref" href="#rfc.iref.c.1"> 2.1</a></li>3468 <li class="indline1">client <a class="iref" href="#rfc.iref.c.1"><b>2.1</b></a></li> 3468 3469 <li class="indline1">Coding Format 3469 3470 <ul class="ind"> … … 3475 3476 </li> 3476 3477 <li class="indline1">compress (Coding Format) <a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li> 3477 <li class="indline1">connection <a class="iref" href="#rfc.iref.c.2"> 2.1</a></li>3478 <li class="indline1">connection <a class="iref" href="#rfc.iref.c.2"><b>2.1</b></a></li> 3478 3479 <li class="indline1">Connection header <a class="iref" href="#rfc.xref.header.connection.1">3.4</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.3</a></li> 3479 3480 <li class="indline1">Content-Length header <a class="iref" href="#rfc.xref.header.content-length.1">3.3</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a></li> … … 3483 3484 <li class="indline1">Date header <a class="iref" href="#rfc.xref.header.date.1">3.4</a>, <a class="iref" href="#rfc.iref.d.3"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li> 3484 3485 <li class="indline1">deflate (Coding Format) <a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li> 3485 <li class="indline1">downstream <a class="iref" href="#rfc.iref.d.1"> 2.2</a></li>3486 <li class="indline1">downstream <a class="iref" href="#rfc.iref.d.1"><b>2.2</b></a></li> 3486 3487 </ul> 3487 3488 </li> 3488 3489 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 3489 <li class="indline1"> Effective Request URI <a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>3490 <li class="indline1">effective request URI <a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li> 3490 3491 </ul> 3491 3492 </li> 3492 3493 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 3493 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.24"> 2.2</a></li>3494 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.24"><b>2.2</b></a></li> 3494 3495 <li class="indline1"><tt>Grammar</tt> 3495 3496 <ul class="ind"> … … 3640 3641 </li> 3641 3642 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 3642 <li class="indline1">inbound <a class="iref" href="#rfc.iref.i.1">2.2</a></li> 3643 <li class="indline1">inbound <a class="iref" href="#rfc.iref.i.2"><b>2.2</b></a></li> 3644 <li class="indline1">intermediary <a class="iref" href="#rfc.iref.i.1"><b>2.2</b></a></li> 3643 3645 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a class="iref" href="#ISO-8859-1"><b>13.1</b></a></li> 3644 3646 </ul> … … 3655 3657 </ul> 3656 3658 </li> 3657 <li class="indline1">message <a class="iref" href="#rfc.iref.m.1"> 2.1</a></li>3659 <li class="indline1">message <a class="iref" href="#rfc.iref.m.1"><b>2.1</b></a></li> 3658 3660 <li class="indline1">message/http Media Type <a class="iref" href="#rfc.iref.m.3"><b>10.3.1</b></a></li> 3659 3661 </ul> … … 3664 3666 </li> 3665 3667 <li class="indline0"><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul class="ind"> 3666 <li class="indline1">origin server <a class="iref" href="#rfc.iref.o.1"> 2.1</a></li>3667 <li class="indline1">outbound <a class="iref" href="#rfc.iref.o.2"> 2.2</a></li>3668 <li class="indline1">origin server <a class="iref" href="#rfc.iref.o.1"><b>2.1</b></a></li> 3669 <li class="indline1">outbound <a class="iref" href="#rfc.iref.o.2"><b>2.2</b></a></li> 3668 3670 </ul> 3669 3671 </li> 3670 3672 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 3671 3673 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>13.2</b></a></li> 3672 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4 </a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind">3673 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a> , <a class="iref" href="#rfc.xref.Part2.3">4</a></li>3674 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a> , <a class="iref" href="#rfc.xref.Part2.6">5</a></li>3675 <li class="indline1"><em>Section 7.1.2</em> <a class="iref" href="#rfc.xref.Part2. 8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a></li>3676 <li class="indline1"><em>Section 7.9</em> <a class="iref" href="#rfc.xref.Part2. 4">4.1.2</a></li>3677 <li class="indline1"><em>Section 8</em> <a class="iref" href="#rfc.xref.Part2. 7">5.1.1</a></li>3678 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2. 10">7.2.3</a></li>3679 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part2.1 3">7.2.3</a></li>3680 <li class="indline1"><em>Section 8.4.15</em> <a class="iref" href="#rfc.xref.Part2. 5">4.1.2</a></li>3681 <li class="indline1"><em>Section 9.2</em> <a class="iref" href="#rfc.xref.Part2. 11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a></li>3674 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.8">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind"> 3675 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a></li> 3676 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a></li> 3677 <li class="indline1"><em>Section 7.1.2</em> <a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a></li> 3678 <li class="indline1"><em>Section 7.9</em> <a class="iref" href="#rfc.xref.Part2.3">4.1.2</a></li> 3679 <li class="indline1"><em>Section 8</em> <a class="iref" href="#rfc.xref.Part2.5">5.1.1</a></li> 3680 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.8">7.2.3</a></li> 3681 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li> 3682 <li class="indline1"><em>Section 8.4.15</em> <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a></li> 3683 <li class="indline1"><em>Section 9.2</em> <a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a></li> 3682 3684 </ul> 3683 3685 </li> 3684 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">6.4</a>, <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a><ul class="ind"> 3685 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a></li> 3686 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li> 3687 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.8">6.4</a></li> 3686 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a>, <a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">6.4</a>, <a class="iref" href="#rfc.xref.Part3.6">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.8">A</a><ul class="ind"> 3687 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a></li> 3688 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.5">6.4</a></li> 3688 3689 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> 3689 <li class="indline1"><em>Appendix A.1</em> <a class="iref" href="#rfc.xref.Part3. 3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a></li>3690 <li class="indline1"><em>Appendix A.1</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a></li> 3690 3691 </ul> 3691 3692 </li> … … 3698 3699 </ul> 3699 3700 </li> 3700 <li class="indline1">proxy <a class="iref" href="#rfc.iref.p.1"> 2.2</a></li>3701 <li class="indline1">proxy <a class="iref" href="#rfc.iref.p.1"><b>2.2</b></a></li> 3701 3702 </ul> 3702 3703 </li> 3703 3704 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 3704 <li class="indline1">request <a class="iref" href="#rfc.iref.r.1"> 2.1</a></li>3705 <li class="indline1">request <a class="iref" href="#rfc.iref.r.1"><b>2.1</b></a></li> 3705 3706 <li class="indline1">resource <a class="iref" href="#rfc.iref.r.4"><b>2.6</b></a></li> 3706 <li class="indline1">response <a class="iref" href="#rfc.iref.r.2"> 2.1</a></li>3707 <li class="indline1">reverse proxy <a class="iref" href="#rfc.iref.r.3"> 2.2</a></li>3707 <li class="indline1">response <a class="iref" href="#rfc.iref.r.2"><b>2.1</b></a></li> 3708 <li class="indline1">reverse proxy <a class="iref" href="#rfc.iref.r.3"><b>2.2</b></a></li> 3708 3709 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">6.1</a>, <a class="iref" href="#RFC1123"><b>13.2</b></a></li> 3709 3710 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">9.3</a>, <a class="iref" href="#RFC1305"><b>13.2</b></a></li> … … 3767 3768 </li> 3768 3769 <li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind"> 3769 <li class="indline1">server <a class="iref" href="#rfc.iref.s.1"> 2.1</a></li>3770 <li class="indline1">server <a class="iref" href="#rfc.iref.s.1"><b>2.1</b></a></li> 3770 3771 <li class="indline1"><em>Spe</em> <a class="iref" href="#rfc.xref.Spe.1">7.1.1</a>, <a class="iref" href="#Spe"><b>13.2</b></a></li> 3772 <li class="indline1">spider <a class="iref" href="#rfc.iref.s.2"><b>2.1</b></a></li> 3771 3773 </ul> 3772 3774 </li> 3773 3775 <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind"> 3774 <li class="indline1">TE header <a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.2"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li> 3776 <li class="indline1">target resource <a class="iref" href="#rfc.iref.t.2"><b>4.3</b></a></li> 3777 <li class="indline1">TE header <a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li> 3775 3778 <li class="indline1"><em>Tou1998</em> <a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>13.2</b></a></li> 3776 <li class="indline1">Trailer header <a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t. 3"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>3777 <li class="indline1">Transfer-Encoding header <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t. 4"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>3778 <li class="indline1">tunnel <a class="iref" href="#rfc.iref.t.1"> 2.2</a></li>3779 <li class="indline1">Trailer header <a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li> 3780 <li class="indline1">Transfer-Encoding header <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.5"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li> 3781 <li class="indline1">tunnel <a class="iref" href="#rfc.iref.t.1"><b>2.2</b></a></li> 3779 3782 </ul> 3780 3783 </li> 3781 3784 <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind"> 3782 3785 <li class="indline1">Upgrade header <a class="iref" href="#rfc.xref.header.upgrade.1">3.4</a>, <a class="iref" href="#rfc.iref.u.5"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li> 3783 <li class="indline1">upstream <a class="iref" href="#rfc.iref.u.2"> 2.2</a></li>3786 <li class="indline1">upstream <a class="iref" href="#rfc.iref.u.2"><b>2.2</b></a></li> 3784 3787 <li class="indline1">URI scheme 3785 3788 <ul class="ind"> … … 3789 3792 </li> 3790 3793 <li class="indline1"><em>USASCII</em> <a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#rfc.xref.USASCII.2">3.2</a>, <a class="iref" href="#USASCII"><b>13.1</b></a></li> 3791 <li class="indline1">user agent <a class="iref" href="#rfc.iref.u.1"> 2.1</a></li>3794 <li class="indline1">user agent <a class="iref" href="#rfc.iref.u.1"><b>2.1</b></a></li> 3792 3795 </ul> 3793 3796 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r964 r966 684 684 to each request, in the order received on that connection, with one or more HTTP response messages. This document defines 685 685 the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various 686 response messages that might be expected as a result of applying that method for the requestedresource.686 response messages that might be expected as a result of applying that method to the target resource. 687 687 </p> 688 688 <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller … … 726 726 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>> 727 727 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 728 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>>728 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 729 729 <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = 730 <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>>730 <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>> 731 731 <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> = 732 <Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>>732 <Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>> 733 733 <a href="#abnf.dependencies" class="smpl">Accept-Language</a> = 734 <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>>734 <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>> 735 735 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">ETag</a> = <ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a>> 736 736 <a href="#abnf.dependencies" class="smpl">If-Match</a> = <If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>> … … 753 753 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>> 754 754 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 756 756 </p> 757 757 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 7.2</a> … … 765 765 / <a href="#method" class="smpl">extension-method</a> 766 766 <a href="#method" class="smpl">extension-method</a> = <a href="#core.rules" class="smpl">token</a> 767 </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 returncode of the response always notifies the client whether a method is currently allowed on a resource, since the768 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> re turn the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested767 </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 the 768 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 769 769 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET 770 770 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 7</a>. … … 790 790 method invocation. 791 791 </p> 792 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a> ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>793 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>794 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>795 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>792 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a> ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> 793 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> 794 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> 795 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> 796 796 / <a href="#abnf.dependencies" class="smpl">Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> 797 797 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> … … 811 811 </pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new 812 812 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. 813 Unrecognized header fields are treated as entity-header fields.814 813 </p> 815 814 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> … … 883 882 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 884 883 Status-Line. These header fields give information about the server and about further access to the resource identified by 885 the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).884 the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 886 885 </p> 887 886 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> … … 897 896 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new 898 897 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header 899 fields. Unrecognized header fields are treated as entity-header fields.898 fields. 900 899 </p> 901 900 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="representation" href="#representation">Representation</a></h1> … … 908 907 </p> 909 908 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 910 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity ofthe resource associated with a representation.</p>909 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 911 910 <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 912 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following911 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 913 912 rules are used (with the first applicable one being selected): 914 913 </p> 915 914 <ol> 916 <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource 917 at the Effective Request URI. 918 </li> 919 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 920 of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 921 </li> 922 <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation 923 of the resource at the Effective Request URI. 924 </li> 925 <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts 926 that it is a representation of the resource at the Content-Location URI (but it might not be). 915 <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the 916 resource identified by the effective request URI. 917 </li> 918 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 919 representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 920 </li> 921 <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload 922 is a representation of the resource identified by the effective request URI. 923 </li> 924 <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response 925 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 926 cannot be trusted unless it can be verified by other means (not defined by HTTP). 927 927 </li> 928 928 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> … … 960 960 <div id="rfc.iref.m.1"></div> 961 961 <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response 962 chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements962 chain identified by the effective request URI. This method allows the client to determine the options and/or requirements 963 963 associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 964 964 </p> … … 986 986 <div id="rfc.iref.m.2"></div> 987 987 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource 988 identified by the Effective Request URI.989 </p> 990 <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation988 identified by the effective request URI. 989 </p> 990 <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation 991 991 in the response and not the source text of the process, unless that text happens to be the output of the process. 992 992 </p> … … 1020 1020 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1021 1021 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be 1022 processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the1022 processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the 1023 1023 following functions: 1024 1024 </p> … … 1029 1029 <li>Extending a database through an append operation.</li> 1030 1030 </ul> 1031 <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request1031 <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request 1032 1032 URI. 1033 1033 </p> … … 1039 1039 a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1040 1040 </p> 1041 <p id="rfc.section.7.5.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1041 <p id="rfc.section.7.5.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1042 1042 </p> 1043 1043 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1047 1047 <div id="rfc.iref.m.5"></div> 1048 1048 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1049 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request1050 URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not1049 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the effective request URI. If the effective request 1050 URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the effective request URI does not 1051 1051 point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the 1052 1052 origin server can create the resource with that URI. 1053 1053 </p> 1054 <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No1054 <p id="rfc.section.7.6.p.2">If a new resource is created at the effective request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 1055 1055 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1056 1056 </p> 1057 <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.1058 </p> 1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.1060 </p> 1061 <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request1057 <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1058 </p> 1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable. 1060 </p> 1061 <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the effective request 1062 1062 URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be 1063 1063 a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in … … 1071 1071 </p> 1072 1072 <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 1073 <p id="rfc.section.7.6.p.8"> Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.1073 <p id="rfc.section.7.6.p.8">Header fields in a PUT request that are recognized as representation metadata <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored. 1074 1074 </p> 1075 1075 <div id="rfc.iref.d.1"></div> 1076 1076 <div id="rfc.iref.m.6"></div> 1077 1077 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1078 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation1078 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1079 1079 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1080 1080 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible … … 1084 1084 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1085 1085 </p> 1086 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached representations,1086 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the effective request URI identifies one or more currently cached representations, 1087 1087 those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method are not cacheable. 1088 1088 </p> … … 1143 1143 <div id="rfc.iref.s.4"></div> 1144 1144 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 1145 <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for 1146 example: 1147 </p> 1145 <p id="rfc.section.8.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> 1148 1146 <dl> 1149 1147 <dt>GET</dt> 1150 <dd>a representation corresponding to the requested resourceis sent in the response;</dd>1148 <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd> 1151 1149 <dt>HEAD</dt> 1152 <dd>the entity-header fields corresponding to the requested resource are sent in the response without anymessage-body;</dd>1150 <dd>the same representation as GET, except without the message-body;</dd> 1153 1151 <dt>POST</dt> 1154 1152 <dd>a representation describing or containing the result of the action;</dd> … … 1185 1183 <div id="rfc.iref.s.7"></div> 1186 1184 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1187 <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-headeris not the definitive set as available from the origin server, but is gathered1185 <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered 1188 1186 from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might 1189 1187 result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate … … 1196 1194 <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 1197 1195 <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body. 1198 The resource metadata and representation metadata in the response message's header fields refer to the requested resource1199 and its current representation, respectively, after the requested action. For example, if a 204 status code is received in1200 response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for1201 th e representation that was successfully PUT to the requested resource.1196 The resource metadata and representation metadata in the response message's header fields refer to the target resource and 1197 its current representation, respectively, after the requested action. For example, if a 204 status code is received in response 1198 to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation 1199 that was successfully PUT. 1202 1200 </p> 1203 1201 <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input … … 1233 1231 <div id="rfc.iref.s.11"></div> 1234 1232 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1235 <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven1236 negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirectits request to that1233 <p id="rfc.section.8.3.1.p.1">The target resource more than one representation, each with its own specific location, and agent-driven negotiation information 1234 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1237 1235 location. 1238 1236 </p> 1239 <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of re source characteristicsand location(s) from which the user or user agent can1237 <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can 1240 1238 choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending 1241 1239 upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. … … 1248 1246 <div id="rfc.iref.s.12"></div> 1249 1247 <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 1250 <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Effective1251 Request URI to one or more of the new references returned by the server, where possible.1248 <p id="rfc.section.8.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective 1249 request URI to one or more of the new references returned by the server, where possible. 1252 1250 </p> 1253 1251 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. … … 1266 1264 <div id="rfc.iref.s.13"></div> 1267 1265 <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> 1268 <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the 1269 client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests. 1266 <p id="rfc.section.8.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1270 1267 </p> 1271 1268 <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1285 1282 <p id="rfc.section.8.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides 1286 1283 an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response, 1287 be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested1288 resource.1284 be redirected again, or end with an error status. The Location URI is not a substitute reference for the effective request 1285 URI. 1289 1286 </p> 1290 1287 <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action … … 1293 1290 </p> 1294 1291 <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be 1295 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resourcesuch1296 that the follow-on representation might be useful without implying that it adequately represents the previously requested1292 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such 1293 that the follow-on representation might be useful to recipients without implying that it adequately represents the target 1297 1294 resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might 1298 1295 be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). … … 1318 1315 <div id="rfc.iref.s.18"></div> 1319 1316 <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 1320 <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests.1317 <p id="rfc.section.8.3.8.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1321 1318 </p> 1322 1319 <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand … … 1360 1357 <div id="rfc.iref.s.23"></div> 1361 1358 <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1362 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary1359 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary 1363 1360 or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1364 1361 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request … … 1368 1365 <div id="rfc.iref.s.24"></div> 1369 1366 <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1370 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1367 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1371 1368 </p> 1372 1369 <div id="rfc.iref.48"></div> … … 1414 1411 <div id="rfc.iref.s.29"></div> 1415 1412 <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3> 1416 <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected1417 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine,1413 <p id="rfc.section.8.4.11.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to 1414 be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine, 1418 1415 whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. 1419 1416 </p> … … 1449 1446 <div id="rfc.iref.s.33"></div> 1450 1447 <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> 1451 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret.1448 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret. 1452 1449 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 1453 1450 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 1454 1451 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 1455 in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.1452 in some servers using fixed-length buffers for reading or manipulating the effective request URI. 1456 1453 </p> 1457 1454 <div id="rfc.iref.57"></div> … … 1459 1456 <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 1460 1457 <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the 1461 requestedresource for the requested method.1458 target resource for the requested method. 1462 1459 </p> 1463 1460 <div id="rfc.iref.58"></div> … … 1523 1520 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1524 1521 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 1525 <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1526 receives the message.1527 </p>1528 1522 <div id="rfc.iref.a.1"></div> 1529 1523 <div id="rfc.iref.h.2"></div> 1530 1524 <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> 1531 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective1532 Request URI. The purpose ofthis field is strictly to inform the recipient of valid methods associated with the resource.1525 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of 1526 this field is strictly to inform the recipient of valid methods associated with the resource. 1533 1527 </p> 1534 1528 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 1615 1609 </div> 1616 1610 <div class="note" id="rfc.section.9.4.p.9"> 1617 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.1611 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 1618 1612 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1619 1613 </p> … … 1636 1630 <div id="rfc.iref.h.7"></div> 1637 1631 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1638 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request1632 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request 1639 1633 URI was obtained (the "referrer", although the header field is misspelled.). 1640 1634 </p> … … 1644 1638 contain a Referer header field. 1645 1639 </p> 1646 <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),1640 <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), 1647 1641 the Referer 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 1648 1642 non-HTTP URIs (e.g., FTP). … … 1652 1646 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1653 1647 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1654 </pre><p id="rfc.section.9.6.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.1648 </pre><p id="rfc.section.9.6.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. 1655 1649 </p> 1656 1650 <div id="rfc.iref.r.2"></div> … … 2259 2253 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>) 2260 2254 </p> 2261 <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requestedresource2255 <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 2262 2256 must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 2263 2257 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 8.3.6</a>) … … 2759 2753 </li> 2760 2754 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind"> 2761 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>2762 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>2763 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>2764 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>2765 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>2766 <li class="indline1"><em>Section 5.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>2755 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li> 2756 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li> 2757 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li> 2758 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li> 2759 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li> 2760 <li class="indline1"><em>Section 6.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li> 2767 2761 </ul> 2768 2762 </li> -
draft-ietf-httpbis/latest/p3-payload.html
r964 r966 377 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 378 378 <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2"> 379 <link rel="Chapter" title="3 Representation" href="#rfc.section.3"> 380 <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4"> 381 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> 382 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> 383 <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"> 384 <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"> 385 <link rel="Chapter" href="#rfc.section.9" title="9 References"> 379 <link rel="Chapter" title="3 Payload" href="#rfc.section.3"> 380 <link rel="Chapter" title="4 Representation" href="#rfc.section.4"> 381 <link rel="Chapter" title="5 Content Negotiation" href="#rfc.section.5"> 382 <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6"> 383 <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"> 384 <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"> 385 <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"> 386 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 386 387 <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"> 387 388 <link rel="Appendix" title="B Additional Features" href="#rfc.section.B"> … … 555 556 </ul> 556 557 </li> 557 <li class="tocline0">3. <a href="#representation">Representation</a><ul class="toc"> 558 <li class="tocline1">3.1 <a href="#entity.header.fields">Entity Header Fields</a></li> 559 <li class="tocline1">3.2 <a href="#payload.body">Payload Body</a><ul class="toc"> 560 <li class="tocline1">3.2.1 <a href="#type">Type</a></li> 561 </ul> 562 </li> 558 <li class="tocline0">3. <a href="#payload">Payload</a><ul class="toc"> 559 <li class="tocline1">3.1 <a href="#payload.header.fields">Payload Header Fields</a></li> 560 <li class="tocline1">3.2 <a href="#payload.body">Payload Body</a></li> 563 561 </ul> 564 562 </li> 565 <li class="tocline0">4. <a href="# content.negotiation">Content Negotiation</a><ul class="toc">566 <li class="tocline1">4.1 <a href="# server-driven.negotiation">Server-driven Negotiation</a></li>567 <li class="tocline1">4.2 <a href="# agent-driven.negotiation">Agent-driven Negotiation</a></li>563 <li class="tocline0">4. <a href="#representation">Representation</a><ul class="toc"> 564 <li class="tocline1">4.1 <a href="#representation.header.fields">Representation Header Fields</a></li> 565 <li class="tocline1">4.2 <a href="#representation.data">Representation Data</a></li> 568 566 </ul> 569 567 </li> 570 <li class="tocline0">5. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 571 <li class="tocline1">5.1 <a href="#header.accept">Accept</a></li> 572 <li class="tocline1">5.2 <a href="#header.accept-charset">Accept-Charset</a></li> 573 <li class="tocline1">5.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 574 <li class="tocline1">5.4 <a href="#header.accept-language">Accept-Language</a></li> 575 <li class="tocline1">5.5 <a href="#header.content-encoding">Content-Encoding</a></li> 576 <li class="tocline1">5.6 <a href="#header.content-language">Content-Language</a></li> 577 <li class="tocline1">5.7 <a href="#header.content-location">Content-Location</a></li> 578 <li class="tocline1">5.8 <a href="#header.content-md5">Content-MD5</a></li> 579 <li class="tocline1">5.9 <a href="#header.content-type">Content-Type</a></li> 568 <li class="tocline0">5. <a href="#content.negotiation">Content Negotiation</a><ul class="toc"> 569 <li class="tocline1">5.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li> 570 <li class="tocline1">5.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li> 580 571 </ul> 581 572 </li> 582 <li class="tocline0">6. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc"> 583 <li class="tocline1">6.1 <a href="#header.field.registration">Header Field Registration</a></li> 584 <li class="tocline1">6.2 <a href="#content.coding.registration">Content Coding Registry</a></li> 573 <li class="tocline0">6. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 574 <li class="tocline1">6.1 <a href="#header.accept">Accept</a></li> 575 <li class="tocline1">6.2 <a href="#header.accept-charset">Accept-Charset</a></li> 576 <li class="tocline1">6.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 577 <li class="tocline1">6.4 <a href="#header.accept-language">Accept-Language</a></li> 578 <li class="tocline1">6.5 <a href="#header.content-encoding">Content-Encoding</a></li> 579 <li class="tocline1">6.6 <a href="#header.content-language">Content-Language</a></li> 580 <li class="tocline1">6.7 <a href="#header.content-location">Content-Location</a></li> 581 <li class="tocline1">6.8 <a href="#header.content-md5">Content-MD5</a></li> 582 <li class="tocline1">6.9 <a href="#header.content-type">Content-Type</a></li> 585 583 </ul> 586 584 </li> 587 <li class="tocline0">7. <a href="# security.considerations">SecurityConsiderations</a><ul class="toc">588 <li class="tocline1">7.1 <a href="# privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>589 <li class="tocline1">7.2 <a href="#content -disposition.issues">Content-Disposition Issues</a></li>585 <li class="tocline0">7. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc"> 586 <li class="tocline1">7.1 <a href="#header.field.registration">Header Field Registration</a></li> 587 <li class="tocline1">7.2 <a href="#content.coding.registration">Content Coding Registry</a></li> 590 588 </ul> 591 589 </li> 592 <li class="tocline0">8. <a href="#ack">Acknowledgments</a></li> 593 <li class="tocline0">9. <a href="#rfc.references">References</a><ul class="toc"> 594 <li class="tocline1">9.1 <a href="#rfc.references.1">Normative References</a></li> 595 <li class="tocline1">9.2 <a href="#rfc.references.2">Informative References</a></li> 590 <li class="tocline0">8. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 591 <li class="tocline1">8.1 <a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li> 592 <li class="tocline1">8.2 <a href="#content-disposition.issues">Content-Disposition Issues</a></li> 593 </ul> 594 </li> 595 <li class="tocline0">9. <a href="#ack">Acknowledgments</a></li> 596 <li class="tocline0">10. <a href="#rfc.references">References</a><ul class="toc"> 597 <li class="tocline1">10.1 <a href="#rfc.references.1">Normative References</a></li> 598 <li class="tocline1">10.2 <a href="#rfc.references.2">Informative References</a></li> 596 599 </ul> 597 600 </li> … … 648 651 <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can 649 652 be negotiated (including error responses). 650 </li>651 </ul>652 <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.p.1"></span> <dfn>payload</dfn>653 </p>654 <ul class="empty">655 <li>The information transferred within a given message is called the payload, consisting of optional payload metadata and an optional656 payload body. The payload in HTTP is always a partial or complete representation of some resource, though which resource is657 represented is dependent on the type of message (request or response), the request method, and the response status code.658 </li>659 </ul>660 <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.r.1"></span> <dfn>representation</dfn>661 </p>662 <ul class="empty">663 <li>A representation is information in a format that can be readily communicated from one party to another. For our purposes,664 a representation is binary data and its associated metadata. A representation of a resource is information that reflects the665 state of that resource, as observed at some point in the past or to be desired at some point in the future.666 653 </li> 667 654 </ul> … … 744 731 </p> 745 732 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 746 </pre><p id="rfc.section.2.2.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.1" title="Accept-Encoding">Section 5.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 5.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding733 </pre><p id="rfc.section.2.2.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.1" title="Accept-Encoding">Section 6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 747 734 mechanism will be required to remove the encoding. 748 735 </p> … … 788 775 </p> 789 776 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="media.types" href="#media.types">Media Types</a></h2> 790 <p id="rfc.section.2.3.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.1" title="Content-Type">Section 5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.777 <p id="rfc.section.2.3.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.1" title="Content-Type">Section 6.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 791 778 </p> 792 779 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></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> ) … … 860 847 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. 861 848 </p> 862 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="representation" href="#representation">Representation</a></h1> 863 <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists 864 of entity-header fields and a representation body, although some responses will only include the entity-headers. 865 </p> 866 <p id="rfc.section.3.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives 867 the message. 868 </p> 869 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2> 870 <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is 871 present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the 872 Effective Request URI. 873 </p> 874 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> <a href="#entity.header.fields" class="smpl">entity-header</a> = <a href="#header.content-encoding" class="smpl">Content-Encoding</a> ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 5.5</a> 875 / <a href="#header.content-language" class="smpl">Content-Language</a> ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 5.6</a> 876 / <a href="#abnf.dependencies" class="smpl">Content-Length</a> ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> 877 / <a href="#header.content-location" class="smpl">Content-Location</a> ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 5.7</a> 878 / <a href="#header.content-md5" class="smpl">Content-MD5</a> ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section 5.8</a> 879 / <a href="#abnf.dependencies" class="smpl">Content-Range</a> ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> 880 / <a href="#header.content-type" class="smpl">Content-Type</a> ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 5.9</a> 881 / <a href="#abnf.dependencies" class="smpl">Expires</a> ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> 882 / <a href="#abnf.dependencies" class="smpl">Last-Modified</a> ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> 883 / <a href="#entity.header.fields" class="smpl">extension-header</a> 884 885 <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">header-field</a> 886 </pre><p id="rfc.section.3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these 887 fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies. 888 </p> 889 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 890 <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 891 <p id="rfc.section.3.2.p.2">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 849 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="payload" href="#payload">Payload</a></h1> 850 <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata, 851 in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding 852 has been decoded. 853 </p> 854 <div id="rfc.iref.p.1"></div> 855 <p id="rfc.section.3.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation 856 because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s) 857 of the representation (e.g., the 206 status code). 858 </p> 859 <p id="rfc.section.3.p.3">define metadata for the whole representation, which we refer to as "representation header fields", while others define only 860 metadata about what is included in the message, which we 861 </p> 862 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h2> 863 <p id="rfc.section.3.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload 864 header fields". The following payload header fields are defined by HTTP/1.1: 865 </p> 866 <div id="rfc.figure.u.12"></div><pre> <a href="#abnf.dependencies" class="smpl">Content-Length</a> ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> 867 <a href="#header.content-md5" class="smpl">Content-MD5</a> ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section 6.8</a> 868 <a href="#abnf.dependencies" class="smpl">Content-Range</a> ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> 869 </pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 870 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 892 871 safe and proper transfer of the message. 893 872 </p> 894 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="type" href="#type">Type</a></h3> 895 <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type 896 and Content-Encoding. These define a two-layer, ordered encoding model: 897 </p> 898 <div id="rfc.figure.u.13"></div><pre class="text"> payload-body := Content-Encoding( Content-Type( data ) ) 899 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a payload body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown. 900 </p> 901 <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. 902 </p> 903 <p id="rfc.section.3.2.1.p.5">In practice, currently-deployed servers sometimes provide a Content-Type header which does not correctly convey the intended 904 interpretation of the content sent, with the result that some clients will examine the response body's content and override 905 the specified type. 906 </p> 907 <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). 908 Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used. 909 </p> 910 <p id="rfc.section.3.2.1.p.7">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, 911 that are a property of the representation. There is no default encoding. 912 </p> 913 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> 914 <p id="rfc.section.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further 873 <div id="rfc.iref.r.1"></div> 874 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="representation" href="#representation">Representation</a></h1> 875 <p id="rfc.section.4.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information 876 that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired 877 at some point in the future (e.g., in a PUT request). 878 </p> 879 <p id="rfc.section.4.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource 880 identified by the effective request URI). The precise semantics of a representation are determined by the type of message 881 (request or response), the request method, the response status code, and the representation metadata. For example, the above 882 semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200 883 response to PUT, in contrast, contains either a representation that describes the successful action or a representation of 884 the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request 885 URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what 886 next steps are suggested for resolving it. 887 </p> 888 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2> 889 <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body 890 is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with 891 the same effective request URI. 892 </p> 893 <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p> 894 <div id="rfc.figure.u.13"></div><pre> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 6.5</a> 895 <a href="#header.content-language" class="smpl">Content-Language</a> ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 6.6</a> 896 <a href="#header.content-location" class="smpl">Content-Location</a> ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 6.7</a> 897 <a href="#header.content-type" class="smpl">Content-Type</a> ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 6.9</a> 898 <a href="#abnf.dependencies" class="smpl">Expires</a> ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> 899 <a href="#abnf.dependencies" class="smpl">Last-Modified</a> ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> 900 </pre><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="representation.data" href="#representation.data">Representation Data</a></h2> 901 <p id="rfc.section.4.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred 902 to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by 903 the representation metadata header fields. 904 </p> 905 <p id="rfc.section.4.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define 906 a two-layer, ordered encoding model: 907 </p> 908 <div id="rfc.figure.u.14"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 909 </pre><p id="rfc.section.4.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 910 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown 911 to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type 912 of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. 913 </p> 914 <p id="rfc.section.4.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for 915 a given representation, with the result that some clients will examine a response body's content and override the specified 916 type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege 917 escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats 918 match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling 919 such "content sniffing" when it is used. 920 </p> 921 <p id="rfc.section.4.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, 922 that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond 923 that defined by the Content-Type. 924 </p> 925 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> 926 <p id="rfc.section.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further 915 927 processing. Often, the server has different ways of representing the same information; for example, in different formats, 916 928 languages, or using different character encodings. 917 929 </p> 918 <p id="rfc.section. 4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence930 <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence 919 931 which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP 920 932 provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource, 921 933 when more than one is available. 922 934 </p> 923 <p id="rfc.section. 4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation935 <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation 924 936 based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations 925 937 for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an … … 927 939 parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed. 928 940 </p> 929 <p id="rfc.section. 4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number941 <p id="rfc.section.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number 930 942 of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by 931 943 a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations 932 944 to choose from is very large, agent-driven negotiation might not be appropriate. 933 945 </p> 934 <p id="rfc.section. 4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might946 <p id="rfc.section.5.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might 935 947 be considered to be the "same information". 936 948 </p> 937 <h2 id="rfc.section. 4.1"><a href="#rfc.section.4.1">4.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>938 <p id="rfc.section. 4.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven949 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2> 950 <p id="rfc.section.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven 939 951 negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g., 940 952 language, content-coding, etc.) and the contents of particular header fields in the request message or on other information 941 953 pertaining to the request (such as the network address of the client). 942 954 </p> 943 <p id="rfc.section. 4.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult955 <p id="rfc.section.5.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult 944 956 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 945 957 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 946 958 improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response. 947 959 </p> 948 <p id="rfc.section. 4.1.p.3">Server-driven negotiation has disadvantages: </p>960 <p id="rfc.section.5.1.p.3">Server-driven negotiation has disadvantages: </p> 949 961 <ol> 950 962 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require … … 958 970 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 959 971 </ol> 960 <p id="rfc.section. 4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent961 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension972 <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent 973 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension 962 974 header fields not defined by this specification. 963 975 </p> 964 <div class="note" id="rfc.section. 4.1.p.5">976 <div class="note" id="rfc.section.5.1.p.5"> 965 977 <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized. 966 978 </p> 967 979 </div> 968 <p id="rfc.section. 4.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.969 </p> 970 <h2 id="rfc.section. 4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>971 <p id="rfc.section. 4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving980 <p id="rfc.section.5.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 981 </p> 982 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> 983 <p id="rfc.section.5.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving 972 984 an initial response from the origin server. Selection is based on a list of the available representations of the response 973 985 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection … … 975 987 user selecting from a generated (possibly hypertext) menu. 976 988 </p> 977 <p id="rfc.section. 4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,989 <p id="rfc.section.5.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, 978 990 or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 979 991 when public caches are used to distribute server load and reduce network usage. 980 992 </p> 981 <p id="rfc.section. 4.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.993 <p id="rfc.section.5.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. 982 994 This second request is only efficient when caching is used. In addition, this specification does not define any mechanism 983 995 for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension 984 996 and used within HTTP/1.1. 985 997 </p> 986 <p id="rfc.section. 4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation998 <p id="rfc.section.5.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation 987 999 when the server is unwilling or unable to provide a varying response using server-driven negotiation. 988 1000 </p> 989 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 990 <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p> 991 <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 992 receives the message. 993 </p> 1001 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1002 <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p> 994 1003 <div id="rfc.iref.a.1"></div> 995 1004 <div id="rfc.iref.h.1"></div> 996 <h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2>997 <p id="rfc.section. 5.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers1005 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 1006 <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers 998 1007 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 999 1008 for an in-line image. 1000 1009 </p> 1001 <div id="rfc.figure.u.1 4"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>1010 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a> 1002 1011 <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 1003 1012 … … 1009 1018 <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> 1010 1019 [ "=" <a href="#core.rules" class="smpl">word</a> ] 1011 </pre><p id="rfc.section. 5.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating1020 </pre><p id="rfc.section.6.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 1012 1021 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 1013 1022 </p> 1014 <p id="rfc.section. 5.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 first1023 <p id="rfc.section.6.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 1015 1024 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1016 1025 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1017 1026 </p> 1018 <div class="note" id="rfc.section. 5.1.p.5">1027 <div class="note" id="rfc.section.6.1.p.5"> 1019 1028 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 1020 1029 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to … … 1023 1032 </p> 1024 1033 </div> 1025 <p id="rfc.section. 5.1.p.6">The example</p>1026 <div id="rfc.figure.u.1 5"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic1027 </pre><p id="rfc.section. 5.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 in1034 <p id="rfc.section.6.1.p.6">The example</p> 1035 <div id="rfc.figure.u.16"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1036 </pre><p id="rfc.section.6.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 1028 1037 quality". 1029 1038 </p> 1030 <p id="rfc.section. 5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field1039 <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field 1031 1040 is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then 1032 1041 the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response. 1033 1042 </p> 1034 <p id="rfc.section. 5.1.p.10">A more elaborate example is</p>1035 <div id="rfc.figure.u.1 6"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,1043 <p id="rfc.section.6.1.p.10">A more elaborate example is</p> 1044 <div id="rfc.figure.u.17"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 1036 1045 text/x-dvi; q=0.8, text/x-c 1037 </pre><p id="rfc.section. 5.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, then1046 </pre><p id="rfc.section.6.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 1038 1047 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 1039 1048 </p> 1040 <p id="rfc.section. 5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies1049 <p id="rfc.section.6.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 1041 1050 to a given type, the most specific reference has precedence. For example, 1042 1051 </p> 1043 <div id="rfc.figure.u.1 7"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */*1044 </pre><p id="rfc.section. 5.1.p.15">have the following precedence: </p>1052 <div id="rfc.figure.u.18"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 1053 </pre><p id="rfc.section.6.1.p.15">have the following precedence: </p> 1045 1054 <ol> 1046 1055 <li>text/html;level=1</li> … … 1049 1058 <li>*/*</li> 1050 1059 </ol> 1051 <p id="rfc.section. 5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence1060 <p id="rfc.section.6.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 1052 1061 which matches that type. For example, 1053 1062 </p> 1054 <div id="rfc.figure.u.1 8"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,1063 <div id="rfc.figure.u.19"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1055 1064 text/html;level=2;q=0.4, */*;q=0.5 1056 </pre><p id="rfc.section. 5.1.p.18">would cause the following values to be associated:</p>1065 </pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p> 1057 1066 <div id="rfc.table.u.1"> 1058 1067 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 1091 1100 </table> 1092 1101 </div> 1093 <p id="rfc.section. 5.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 agent1102 <p id="rfc.section.6.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 1094 1103 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 1095 1104 </p> 1096 1105 <div id="rfc.iref.a.2"></div> 1097 1106 <div id="rfc.iref.h.2"></div> 1098 <h2 id="rfc.section. 5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>1099 <p id="rfc.section. 5.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.1107 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 1108 <p id="rfc.section.6.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable. 1100 1109 This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability 1101 1110 to a server which is capable of representing documents in those character sets. 1102 1111 </p> 1103 <div id="rfc.figure.u. 19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>1112 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a> 1104 1113 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> 1105 1114 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 1106 1115 [ <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> ] ) 1107 </pre><p id="rfc.section. 5.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section 2.1</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. An1116 </pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section 2.1</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 1108 1117 example is 1109 1118 </p> 1110 <div id="rfc.figure.u.2 0"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.81111 </pre><p id="rfc.section. 5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is1119 <div id="rfc.figure.u.21"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1120 </pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is 1112 1121 not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets 1113 1122 not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly 1114 1123 mentioned. 1115 1124 </p> 1116 <p id="rfc.section. 5.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is1125 <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is 1117 1126 present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed. 1118 1127 </p> 1119 1128 <div id="rfc.iref.a.3"></div> 1120 1129 <div id="rfc.iref.h.3"></div> 1121 <h2 id="rfc.section. 5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>1122 <p id="rfc.section. 5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response.1123 </p> 1124 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>1130 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 1131 <p id="rfc.section.6.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response. 1132 </p> 1133 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> 1125 1134 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> 1126 1135 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> = 1127 1136 #( <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> ] ) 1128 1137 <a href="#header.accept-encoding" class="smpl">codings</a> = ( <a href="#content.codings" class="smpl">content-coding</a> / "*" ) 1129 </pre><p id="rfc.section. 5.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.1130 </p> 1131 <p id="rfc.section. 5.3.p.4">Examples of its use are:</p>1132 <div id="rfc.figure.u.2 2"></div><pre class="text"> Accept-Encoding: compress, gzip1138 </pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1. 1139 </p> 1140 <p id="rfc.section.6.3.p.4">Examples of its use are:</p> 1141 <div id="rfc.figure.u.23"></div><pre class="text"> Accept-Encoding: compress, gzip 1133 1142 Accept-Encoding: 1134 1143 Accept-Encoding: * 1135 1144 Accept-Encoding: compress;q=0.5, gzip;q=1.0 1136 1145 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 1137 </pre><p id="rfc.section. 5.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>1146 </pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p> 1138 1147 <ol> 1139 1148 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it … … 1149 1158 </li> 1150 1159 </ol> 1151 <p id="rfc.section. 5.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according1160 <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according 1152 1161 to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code. 1153 1162 </p> 1154 <p id="rfc.section. 5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,1163 <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, 1155 1164 then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the 1156 1165 client. 1157 1166 </p> 1158 <div class="note" id="rfc.section. 5.3.p.9">1167 <div class="note" id="rfc.section.6.3.p.9"> 1159 1168 <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings 1160 1169 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display … … 1163 1172 </p> 1164 1173 </div> 1165 <div class="note" id="rfc.section. 5.3.p.10">1174 <div class="note" id="rfc.section.6.3.p.10"> 1166 1175 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 1167 1176 not work and are not permitted with x-gzip or x-compress. … … 1170 1179 <div id="rfc.iref.a.4"></div> 1171 1180 <div id="rfc.iref.h.4"></div> 1172 <h2 id="rfc.section. 5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>1173 <p id="rfc.section. 5.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred1181 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 1182 <p id="rfc.section.6.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred 1174 1183 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1175 1184 </p> 1176 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>1185 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a> 1177 1186 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> 1178 1187 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> = … … 1180 1189 <a href="#header.accept-language" class="smpl">language-range</a> = 1181 1190 <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>> 1182 </pre><p id="rfc.section. 5.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the1191 </pre><p id="rfc.section.6.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the 1183 1192 languages specified by that range. The quality value defaults to "q=1". For example, 1184 1193 </p> 1185 <div id="rfc.figure.u.2 4"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71186 </pre><p id="rfc.section. 5.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>)1187 </p> 1188 <p id="rfc.section. 5.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.1189 </p> 1190 <div class="note" id="rfc.section. 5.4.p.7">1194 <div id="rfc.figure.u.25"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1195 </pre><p id="rfc.section.6.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>) 1196 </p> 1197 <p id="rfc.section.6.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. 1198 </p> 1199 <div class="note" id="rfc.section.6.4.p.7"> 1191 1200 <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.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1192 1201 </p> 1193 1202 </div> 1194 <p id="rfc.section. 5.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic1195 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 7.1</a>.1196 </p> 1197 <p id="rfc.section. 5.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice1203 <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic 1204 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 8.1</a>. 1205 </p> 1206 <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 1198 1207 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. 1199 1208 </p> 1200 <div class="note" id="rfc.section. 5.4.p.10">1209 <div class="note" id="rfc.section.6.4.p.10"> 1201 1210 <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 1202 1211 familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, … … 1207 1216 <div id="rfc.iref.c.7"></div> 1208 1217 <div id="rfc.iref.h.5"></div> 1209 <h2 id="rfc.section. 5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>1210 <p id="rfc.section. 5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the representation, and thus1211 whatdecoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding1218 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 1219 <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what 1220 decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding 1212 1221 is primarily used to allow a representation to be compressed without losing the identity of its underlying media type. 1213 1222 </p> 1214 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>1223 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> 1215 1224 <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 1216 </pre><p id="rfc.section. 5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is1217 </p> 1218 <div id="rfc.figure.u.2 6"></div><pre class="text"> Content-Encoding: gzip1219 </pre><p id="rfc.section. 5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding1225 </pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is 1226 </p> 1227 <div id="rfc.figure.u.27"></div><pre class="text"> Content-Encoding: gzip 1228 </pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 1220 1229 and is only decoded before rendering or analogous usage. However, a non-transparent 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 1221 1230 directive is present in the message. 1222 1231 </p> 1223 <p id="rfc.section. 5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 5.5</a>) that lists the non-identity content-coding(s) used.1224 </p> 1225 <p id="rfc.section. 5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).1226 </p> 1227 <p id="rfc.section. 5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1232 <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 6.5</a>) that lists the non-identity content-coding(s) used. 1233 </p> 1234 <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type). 1235 </p> 1236 <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1228 1237 </p> 1229 1238 <div id="rfc.iref.c.8"></div> 1230 1239 <div id="rfc.iref.h.6"></div> 1231 <h2 id="rfc.section. 5.6"><a href="#rfc.section.5.6">5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2>1232 <p id="rfc.section. 5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.1233 Notethat this might not be equivalent to all the languages used within the representation.1234 </p> 1235 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>1240 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 1241 <p id="rfc.section.6.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 1242 that this might not be equivalent to all the languages used within the representation. 1243 </p> 1244 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a> 1236 1245 <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 1237 </pre><p id="rfc.section. 5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the1246 </pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 1238 1247 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 1239 1248 field is 1240 1249 </p> 1241 <div id="rfc.figure.u.2 8"></div><pre class="text"> Content-Language: da1242 </pre><p id="rfc.section. 5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean1250 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: da 1251 </pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1243 1252 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 1244 1253 it is intended. 1245 1254 </p> 1246 <p id="rfc.section. 5.6.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", presented1255 <p id="rfc.section.6.6.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 1247 1256 simultaneously in the original Maori and English versions, would call for 1248 1257 </p> 1249 <div id="rfc.figure.u. 29"></div><pre class="text"> Content-Language: mi, en1250 </pre><p id="rfc.section. 5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple1258 <div id="rfc.figure.u.30"></div><pre class="text"> Content-Language: mi, en 1259 </pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 1251 1260 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 1252 1261 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1253 1262 </p> 1254 <p id="rfc.section. 5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.1263 <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents. 1255 1264 </p> 1256 1265 <div id="rfc.iref.c.9"></div> 1257 1266 <div id="rfc.iref.h.7"></div> 1258 <h2 id="rfc.section. 5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2>1259 <p id="rfc.section. 5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this1267 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 1268 <p id="rfc.section.6.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 1260 1269 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 1261 1270 would contain the same representation that is enclosed as payload in this message. 1262 1271 </p> 1263 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>1272 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a> 1264 1273 <a href="#header.content-location" class="smpl">Content-Location-v</a> 1265 1274 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1266 1275 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1267 </pre><p id="rfc.section. 5.7.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><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 MIME1276 </pre><p id="rfc.section.6.7.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><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 1268 1277 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. 1269 1278 </p> 1270 <p id="rfc.section. 5.7.p.4">If Content-Location is included in a response message and its value is the same as the Effective Request URI, then the response1279 <p id="rfc.section.6.7.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 1271 1280 payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 1272 1281 when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's … … 1275 1284 need for a subsequent GET request. 1276 1285 </p> 1277 <p id="rfc.section. 5.7.p.5">If Content-Location is included in a response message and its value differs from the Effective Request URI, then the origin1286 <p id="rfc.section.6.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 1278 1287 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 1279 request, this is an indication that the Effective Request URI identifies a resource that is subject to content negotiation1288 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation 1280 1289 and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location 1281 1290 indicates that this representation contains a report on the action's status and the same report is available (for future access … … 1284 1293 in the future. 1285 1294 </p> 1286 <p id="rfc.section. 5.7.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 enclosed1295 <p id="rfc.section.6.7.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 1287 1296 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 1288 1297 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 … … 1292 1301 latter semantics, it would have applied the PUT directly to the Content-Location URI. 1293 1302 </p> 1294 <p id="rfc.section. 5.7.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 use1303 <p id="rfc.section.6.7.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 1295 1304 in other contexts, such as within source links or other metadata. 1296 1305 </p> 1297 <p id="rfc.section. 5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used1306 <p id="rfc.section.6.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 1298 1307 to respond to later requests on that Content-Location URI. 1299 1308 </p> 1300 <p id="rfc.section. 5.7.p.9">If the Content-Location value is a partial URI, it is interpreted relative to the Effective Request URI.</p>1309 <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 1301 1310 <div id="rfc.iref.c.10"></div> 1302 1311 <div id="rfc.iref.h.8"></div> 1303 <h2 id="rfc.section. 5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>1304 <p id="rfc.section. 5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the1312 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1313 <p id="rfc.section.6.8.p.1">The "Content-MD5" header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the 1305 1314 message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload 1306 1315 body in transit, but is not proof against malicious attacks. 1307 1316 </p> 1308 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>1317 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a> 1309 1318 <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1310 </pre><p id="rfc.section. 5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user1319 </pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user 1311 1320 agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received. 1312 1321 </p> 1313 <p id="rfc.section. 5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding1322 <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding 1314 1323 applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response 1315 1324 chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload. 1316 1325 </p> 1317 <p id="rfc.section. 5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),1326 <p id="rfc.section.6.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1318 1327 but this does not change how the digest is computed as defined in the preceding paragraph. 1319 1328 </p> 1320 <p id="rfc.section. 5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding1329 <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding 1321 1330 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the 1322 1331 body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. 1323 1332 The Transfer-Encoding header field is not allowed within body-parts. 1324 1333 </p> 1325 <p id="rfc.section. 5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.1326 </p> 1327 <div class="note" id="rfc.section. 5.8.p.8">1334 <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1335 </p> 1336 <div class="note" id="rfc.section.6.8.p.8"> 1328 1337 <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1329 1338 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One … … 1336 1345 <div id="rfc.iref.c.11"></div> 1337 1346 <div id="rfc.iref.h.9"></div> 1338 <h2 id="rfc.section. 5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2>1339 <p id="rfc.section. 5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD1340 method,the media type is that which would have been sent had the request been a GET.1341 </p> 1342 <div id="rfc.figure.u.3 2"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>1347 <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1348 <p id="rfc.section.6.9.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 1349 the media type is that which would have been sent had the request been a GET. 1350 </p> 1351 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a> 1343 1352 <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a> 1344 </pre><p id="rfc.section. 5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is1345 </p> 1346 <div id="rfc.figure.u.3 3"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41347 </pre><p id="rfc.section. 5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section 3.2.1</a>.1348 </p> 1349 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1350 <h2 id="rfc.section. 6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>1351 <p id="rfc.section. 6.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1353 </pre><p id="rfc.section.6.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is 1354 </p> 1355 <div id="rfc.figure.u.34"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1356 </pre><p id="rfc.section.6.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 4.2</a>. 1357 </p> 1358 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1359 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1360 <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1352 1361 </p> 1353 1362 <div id="rfc.table.1"> … … 1367 1376 <td class="left">http</td> 1368 1377 <td class="left">standard</td> 1369 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 5.1</a>1378 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 6.1</a> 1370 1379 </td> 1371 1380 </tr> … … 1374 1383 <td class="left">http</td> 1375 1384 <td class="left">standard</td> 1376 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 5.2</a>1385 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 6.2</a> 1377 1386 </td> 1378 1387 </tr> … … 1381 1390 <td class="left">http</td> 1382 1391 <td class="left">standard</td> 1383 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 5.3</a>1392 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 6.3</a> 1384 1393 </td> 1385 1394 </tr> … … 1388 1397 <td class="left">http</td> 1389 1398 <td class="left">standard</td> 1390 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 5.4</a>1399 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 6.4</a> 1391 1400 </td> 1392 1401 </tr> … … 1402 1411 <td class="left">http</td> 1403 1412 <td class="left">standard</td> 1404 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section 5.5</a>1413 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section 6.5</a> 1405 1414 </td> 1406 1415 </tr> … … 1409 1418 <td class="left">http</td> 1410 1419 <td class="left">standard</td> 1411 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 5.6</a>1420 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 6.6</a> 1412 1421 </td> 1413 1422 </tr> … … 1416 1425 <td class="left">http</td> 1417 1426 <td class="left">standard</td> 1418 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 5.7</a>1427 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 6.7</a> 1419 1428 </td> 1420 1429 </tr> … … 1423 1432 <td class="left">http</td> 1424 1433 <td class="left">standard</td> 1425 <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section 5.8</a>1434 <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section 6.8</a> 1426 1435 </td> 1427 1436 </tr> … … 1430 1439 <td class="left">http</td> 1431 1440 <td class="left">standard</td> 1432 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 5.9</a>1441 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 6.9</a> 1433 1442 </td> 1434 1443 </tr> … … 1443 1452 </table> 1444 1453 </div> 1445 <p id="rfc.section. 6.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1446 <h2 id="rfc.section. 6.2"><a href="#rfc.section.6.2">6.2</a> <a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>1447 <p id="rfc.section. 6.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section 2.2.1</a> of this document.1448 </p> 1449 <p id="rfc.section. 6.2.p.2">The HTTP Content Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> should be updated with the registration below:1454 <p id="rfc.section.7.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1455 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2> 1456 <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section 2.2.1</a> of this document. 1457 </p> 1458 <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> should be updated with the registration below: 1450 1459 </p> 1451 1460 <div id="rfc.table.2"> … … 1488 1497 </table> 1489 1498 </div> 1490 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1491 <p id="rfc.section. 7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.11499 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1500 <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 1492 1501 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 1493 1502 make some suggestions for reducing security risks. 1494 1503 </p> 1495 <h2 id="rfc.section. 7.1"><a href="#rfc.section.7.1">7.1</a> <a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>1496 <p id="rfc.section. 7.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header1504 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2> 1505 <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header 1497 1506 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 1498 1507 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option … … 1500 1509 process include a message which makes the user aware of the loss of privacy involved. 1501 1510 </p> 1502 <p id="rfc.section. 7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,1511 <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, 1503 1512 and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any 1504 1513 Vary response-header fields generated by the server, that such sending could improve the quality of service. 1505 1514 </p> 1506 <p id="rfc.section. 7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be1515 <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be 1507 1516 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 1508 1517 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions … … 1512 1521 filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 1513 1522 </p> 1514 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>1515 <p id="rfc.section. 7.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the1523 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2> 1524 <p id="rfc.section.8.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the 1516 1525 HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See <a href="http://tools.ietf.org/html/rfc2183#section-5">Section 5</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> for details. 1517 1526 </p> 1518 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1519 <h1 id="rfc.references"><a id="rfc.section. 9" href="#rfc.section.9">9.</a> References1527 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1528 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References 1520 1529 </h1> 1521 <h2 id="rfc.references.1"><a href="#rfc.section. 9.1" id="rfc.section.9.1">9.1</a> Normative References1530 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 1522 1531 </h2> 1523 1532 <table> … … 1605 1614 </tr> 1606 1615 </table> 1607 <h2 id="rfc.references.2"><a href="#rfc.section. 9.2" id="rfc.section.9.2">9.2</a> Informative References1616 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 1608 1617 </h2> 1609 1618 <table> … … 1724 1733 environments. 1725 1734 </p> 1726 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>1735 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a> 1727 1736 <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> 1728 1737 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this … … 1782 1791 in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>. 1783 1792 </p> 1784 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>1793 <div id="rfc.figure.u.36"></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><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a> 1785 1794 <a href="#content-disposition" class="smpl">content-disposition-v</a> 1786 1795 <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a> … … 1792 1801 <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a> 1793 1802 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1794 <div id="rfc.figure.u.3 6"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext"1803 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1795 1804 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1796 1805 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. … … 1799 1808 agent should not display the response, but directly enter a "save response as..." dialog. 1800 1809 </p> 1801 <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section 7.2</a> for Content-Disposition security issues.1810 <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section 8.2</a> for Content-Disposition security issues. 1802 1811 </p> 1803 1812 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> … … 1806 1815 <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken 1807 1816 servers emitting bogus Content-Location headers, and also the potentially undesirable effect of potentially breaking relative 1808 links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 5.7</a>)1817 links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 6.7</a>) 1809 1818 </p> 1810 1819 <p id="rfc.section.C.p.3">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix A.5</a>) 1811 1820 </p> 1812 1821 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1813 <div id="rfc.figure.u.3 7"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v1822 <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v 1814 1823 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v 1815 1824 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" … … 1868 1877 <a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token 1869 1878 1870 <a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length1871 / Content-Location / Content-MD5 / Content-Range / Content-Type /1872 Expires / Last-Modified / extension-header1873 <a href="#entity.header.fields" class="smpl">extension-header</a> = header-field1874 1875 1879 <a href="#content-disposition" class="smpl">filename-parm</a> = "filename=" quoted-string 1876 1880 … … 1898 1902 1899 1903 <a href="#core.rules" class="smpl">word</a> = <word, defined in [Part1], Section 1.2.2> 1900 </pre> <div id="rfc.figure.u.3 8"></div>1904 </pre> <div id="rfc.figure.u.39"></div> 1901 1905 <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used 1902 1906 ; Accept-Charset defined but not used … … 1905 1909 ; MIME-Version defined but not used 1906 1910 ; content-disposition defined but not used 1907 ; entity-header defined but not used1908 1911 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 1909 1912 <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a> Since RFC2616 … … 2090 2093 <ul class="ind"> 2091 2094 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 2092 <li class="indline1">Accept header <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2"> 4.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>2093 <li class="indline1">Accept-Charset header <a class="iref" href="#rfc.xref.header.accept-charset.1"> 4.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>2094 <li class="indline1">Accept-Encoding header <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2"> 4.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>2095 <li class="indline1">Accept-Language header <a class="iref" href="#rfc.xref.header.accept-language.1"> 4.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>2095 <li class="indline1">Accept header <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li> 2096 <li class="indline1">Accept-Charset header <a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li> 2097 <li class="indline1">Accept-Encoding header <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li> 2098 <li class="indline1">Accept-Language header <a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li> 2096 2099 </ul> 2097 2100 </li> 2098 2101 <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind"> 2099 <li class="indline1"><em>BCP97</em> <a class="iref" href="#rfc.xref.BCP97.1"> 9.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">9.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">9.1</a>, <a class="iref" href="#BCP97"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li>2102 <li class="indline1"><em>BCP97</em> <a class="iref" href="#rfc.xref.BCP97.1">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">10.1</a>, <a class="iref" href="#BCP97"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li> 2100 2103 </ul> 2101 2104 </li> … … 2111 2114 <li class="indline1">compress (Coding Format) <a class="iref" href="#rfc.iref.c.2">2.2</a></li> 2112 2115 <li class="indline1">content negotiation <a class="iref" href="#rfc.iref.c.1">1.1</a></li> 2113 <li class="indline1">Content-Disposition header <a class="iref" href="#rfc.xref.content-disposition.1"> 6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>2114 <li class="indline1">Content-Encoding header <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2"> 3.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>2115 <li class="indline1">Content-Language header <a class="iref" href="#rfc.xref.header.content-language.1"> 3.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>2116 <li class="indline1">Content-Location header <a class="iref" href="#rfc.xref.header.content-location.1"> 3.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>2117 <li class="indline1">Content-MD5 header <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b> 5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>2118 <li class="indline1">Content-Type header <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2"> 3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>2116 <li class="indline1">Content-Disposition header <a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li> 2117 <li class="indline1">Content-Encoding header <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li> 2118 <li class="indline1">Content-Language header <a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li> 2119 <li class="indline1">Content-Location header <a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li> 2120 <li class="indline1">Content-MD5 header <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li> 2121 <li class="indline1">Content-Type header <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li> 2119 2122 </ul> 2120 2123 </li> … … 2126 2129 <li class="indline1"><tt>Grammar</tt> 2127 2130 <ul class="ind"> 2128 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.1 3"><b>5.1</b></a></li>2129 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.1 8"><b>5.2</b></a></li>2130 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g.1 9"><b>5.2</b></a></li>2131 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g. 20"><b>5.3</b></a></li>2132 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g. 21"><b>5.3</b></a></li>2133 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.1 7"><b>5.1</b></a></li>2134 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.2 3"><b>5.4</b></a></li>2135 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.2 4"><b>5.4</b></a></li>2136 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.1 6"><b>5.1</b></a></li>2137 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.1 4"><b>5.1</b></a></li>2131 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.11"><b>6.1</b></a></li> 2132 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.16"><b>6.2</b></a></li> 2133 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g.17"><b>6.2</b></a></li> 2134 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.18"><b>6.3</b></a></li> 2135 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.19"><b>6.3</b></a></li> 2136 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.15"><b>6.1</b></a></li> 2137 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.21"><b>6.4</b></a></li> 2138 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.22"><b>6.4</b></a></li> 2139 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.14"><b>6.1</b></a></li> 2140 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.12"><b>6.1</b></a></li> 2138 2141 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li> 2139 2142 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li> 2140 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.2 2"><b>5.3</b></a></li>2143 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.20"><b>6.3</b></a></li> 2141 2144 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> 2142 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 2143 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2144 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li> 2145 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li> 2146 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li> 2147 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li> 2148 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li> 2149 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li> 2150 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li> 2151 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li> 2152 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li> 2153 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li> 2154 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li> 2155 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li> 2156 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2157 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2158 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li> 2159 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li> 2160 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2161 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li> 2145 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li> 2146 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li> 2147 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.24"><b>6.5</b></a></li> 2148 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.25"><b>6.5</b></a></li> 2149 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.26"><b>6.6</b></a></li> 2150 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.27"><b>6.6</b></a></li> 2151 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.28"><b>6.7</b></a></li> 2152 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.29"><b>6.7</b></a></li> 2153 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.30"><b>6.8</b></a></li> 2154 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.31"><b>6.8</b></a></li> 2155 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.32"><b>6.9</b></a></li> 2156 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.33"><b>6.9</b></a></li> 2157 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2158 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2159 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2160 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 2161 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2162 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.23"><b>6.4</b></a></li> 2162 2163 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li> 2163 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.1 5"><b>5.1</b></a></li>2164 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.13"><b>6.1</b></a></li> 2164 2165 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li> 2165 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.3 6"><b>A.1</b></a></li>2166 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.3 7"><b>A.1</b></a></li>2166 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.34"><b>A.1</b></a></li> 2167 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.35"><b>A.1</b></a></li> 2167 2168 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li> 2168 2169 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li> … … 2177 2178 <li class="indline1">Headers 2178 2179 <ul class="ind"> 2179 <li class="indline1">Accept <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2"> 4.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>2180 <li class="indline1">Accept-Charset <a class="iref" href="#rfc.xref.header.accept-charset.1"> 4.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>2181 <li class="indline1">Accept-Encoding <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2"> 4.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>2182 <li class="indline1">Accept-Language <a class="iref" href="#rfc.xref.header.accept-language.1"> 4.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>2183 <li class="indline1">Content-Disposition <a class="iref" href="#rfc.xref.content-disposition.1"> 6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>2184 <li class="indline1">Content-Encoding <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2"> 3.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>2185 <li class="indline1">Content-Language <a class="iref" href="#rfc.xref.header.content-language.1"> 3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>2186 <li class="indline1">Content-Location <a class="iref" href="#rfc.xref.header.content-location.1"> 3.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>2187 <li class="indline1">Content-MD5 <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b> 5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>2188 <li class="indline1">Content-Type <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2"> 3.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>2189 <li class="indline1">MIME-Version <a class="iref" href="#rfc.xref.mime-version.1"> 6.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li>2180 <li class="indline1">Accept <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li> 2181 <li class="indline1">Accept-Charset <a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li> 2182 <li class="indline1">Accept-Encoding <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li> 2183 <li class="indline1">Accept-Language <a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li> 2184 <li class="indline1">Content-Disposition <a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li> 2185 <li class="indline1">Content-Encoding <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li> 2186 <li class="indline1">Content-Language <a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li> 2187 <li class="indline1">Content-Location <a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li> 2188 <li class="indline1">Content-MD5 <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li> 2189 <li class="indline1">Content-Type <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li> 2190 <li class="indline1">MIME-Version <a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li> 2190 2191 </ul> 2191 2192 </li> … … 2194 2195 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 2195 2196 <li class="indline1">identity (Coding Format) <a class="iref" href="#rfc.iref.i.1">2.2</a></li> 2196 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b> 9.1</b></a></li>2197 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>10.1</b></a></li> 2197 2198 </ul> 2198 2199 </li> 2199 2200 <li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind"> 2200 <li class="indline1">MIME-Version header <a class="iref" href="#rfc.xref.mime-version.1"> 6.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li>2201 <li class="indline1">MIME-Version header <a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li> 2201 2202 </ul> 2202 2203 </li> 2203 2204 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2204 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19"> 5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.7</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">2205 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a>, <a class="iref" href="#rfc.xref.Part1.21">6.7</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a>, <a class="iref" href="#Part1"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind"> 2205 2206 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a></li> 2206 2207 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li> … … 2208 2209 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li> 2209 2210 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.18">3.2</a></li> 2210 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.21"> 5.7</a></li>2211 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.21">6.7</a></li> 2211 2212 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.25">A.3</a></li> 2212 2213 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li> 2213 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22"> 6.2</a></li>2214 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a></li> 2214 2215 <li class="indline1"><em>Section 6.2.2</em> <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li> 2215 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23"> 6.2</a></li>2216 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24"> 6.2</a></li>2217 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19"> 5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a></li>2216 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a></li> 2217 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a></li> 2218 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a></li> 2218 2219 <li class="indline1"><em>Section 9.2</em> <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li> 2219 2220 <li class="indline1"><em>Section 9.7</em> <a class="iref" href="#rfc.xref.Part1.26">A.6</a></li> 2220 2221 </ul> 2221 2222 </li> 2222 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1"> 4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">2223 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part2.1"> 4.1</a></li>2223 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">5.1</a>, <a class="iref" href="#Part2"><b>10.1</b></a><ul class="ind"> 2224 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part2.1">5.1</a></li> 2224 2225 </ul> 2225 2226 </li> 2226 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2"> 3.1</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">2227 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2"> 3.1</a></li>2227 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a>, <a class="iref" href="#Part4"><b>10.1</b></a><ul class="ind"> 2228 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a></li> 2228 2229 </ul> 2229 2230 </li> 2230 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b> 9.1</b></a><ul class="ind">2231 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind"> 2231 2232 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li> 2232 2233 </ul> 2233 2234 </li> 2234 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2"> 3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">2235 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2"> 3.1</a></li>2236 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.3"> 4.1</a></li>2235 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.1</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind"> 2236 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li> 2237 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.3">5.1</a></li> 2237 2238 </ul> 2238 2239 </li> 2239 <li class="indline1">payload <a class="iref" href="#rfc.iref.p.1"> 1.1</a></li>2240 <li class="indline1">payload <a class="iref" href="#rfc.iref.p.1">3</a></li> 2240 2241 </ul> 2241 2242 </li> 2242 2243 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 2243 <li class="indline1">representation <a class="iref" href="#rfc.iref.r.1"> 1.1</a></li>2244 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1"> 5.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">5.8</a>, <a class="iref" href="#RFC1864"><b>9.1</b></a></li>2245 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>2246 <li class="indline1"><em>RFC1950</em> <a class="iref" href="#rfc.xref.RFC1950.1"> 6.2</a>, <a class="iref" href="#RFC1950"><b>9.1</b></a></li>2247 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1"> 6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>2248 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1"> 6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>2249 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b> 9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>2250 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3"> 3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">2251 <li class="indline1"><em>Section 4.5.1</em> <a class="iref" href="#rfc.xref.RFC2046.3"> 3.2.1</a></li>2244 <li class="indline1">representation <a class="iref" href="#rfc.iref.r.1">4</a></li> 2245 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1">6.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">6.8</a>, <a class="iref" href="#RFC1864"><b>10.1</b></a></li> 2246 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 2247 <li class="indline1"><em>RFC1950</em> <a class="iref" href="#rfc.xref.RFC1950.1">7.2</a>, <a class="iref" href="#RFC1950"><b>10.1</b></a></li> 2248 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1">7.2</a>, <a class="iref" href="#RFC1951"><b>10.1</b></a></li> 2249 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1">7.2</a>, <a class="iref" href="#RFC1952"><b>10.1</b></a></li> 2250 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li> 2251 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">4.2</a>, <a class="iref" href="#RFC2046"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind"> 2252 <li class="indline1"><em>Section 4.5.1</em> <a class="iref" href="#rfc.xref.RFC2046.3">4.2</a></li> 2252 2253 <li class="indline1"><em>Section 5.1.1</em> <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a></li> 2253 2254 </ul> 2254 2255 </li> 2255 <li class="indline1"><em>RFC2049</em> <a class="iref" href="#RFC2049"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">2256 <li class="indline1"><em>RFC2049</em> <a class="iref" href="#RFC2049"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind"> 2256 2257 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li> 2257 2258 </ul> 2258 2259 </li> 2259 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1"> 9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">9.1</a>, <a class="iref" href="#RFC2068"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li>2260 <li class="indline1"><em>RFC2076</em> <a class="iref" href="#RFC2076"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>2261 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b> 9.1</b></a></li>2262 <li class="indline1"><em>RFC2183</em> <a class="iref" href="#rfc.xref.RFC2183.1"> 7.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">7.2</a>, <a class="iref" href="#RFC2183"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind">2263 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.RFC2183.2"> 7.2</a></li>2260 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">10.1</a>, <a class="iref" href="#RFC2068"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li> 2261 <li class="indline1"><em>RFC2076</em> <a class="iref" href="#RFC2076"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li> 2262 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>10.1</b></a></li> 2263 <li class="indline1"><em>RFC2183</em> <a class="iref" href="#rfc.xref.RFC2183.1">8.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">8.2</a>, <a class="iref" href="#RFC2183"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind"> 2264 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.RFC2183.2">8.2</a></li> 2264 2265 </ul> 2265 2266 </li> 2266 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b> 9.2</b></a></li>2267 <li class="indline1"><em>RFC2295</em> <a class="iref" href="#rfc.xref.RFC2295.1"> 4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>2268 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b> 9.2</b></a></li>2269 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#rfc.xref.RFC2557.1"> 5.7</a>, <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind">2270 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2557.1"> 5.7</a></li>2267 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>10.2</b></a></li> 2268 <li class="indline1"><em>RFC2295</em> <a class="iref" href="#rfc.xref.RFC2295.1">5</a>, <a class="iref" href="#RFC2295"><b>10.2</b></a></li> 2269 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>10.2</b></a></li> 2270 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#rfc.xref.RFC2557.1">6.7</a>, <a class="iref" href="#RFC2557"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind"> 2271 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2557.1">6.7</a></li> 2271 2272 </ul> 2272 2273 </li> 2273 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2"> 5.4</a>, <a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">2274 <li class="indline1"><em>Section 14.4</em> <a class="iref" href="#rfc.xref.RFC2616.2"> 5.4</a></li>2274 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">6.4</a>, <a class="iref" href="#RFC2616"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind"> 2275 <li class="indline1"><em>Section 14.4</em> <a class="iref" href="#rfc.xref.RFC2616.2">6.4</a></li> 2275 2276 </ul> 2276 2277 </li> 2277 <li class="indline1"><em>RFC3629</em> <a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b> 9.2</b></a></li>2278 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1"> 6.1</a>, <a class="iref" href="#RFC3864"><b>9.2</b></a></li>2279 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b> 9.2</b></a></li>2280 <li class="indline1"><em>RFC4647</em> <a class="iref" href="#rfc.xref.RFC4647.1"> 5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">5.4</a>, <a class="iref" href="#RFC4647"><b>9.1</b></a><ul class="ind">2281 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC4647.1"> 5.4</a></li>2282 <li class="indline1"><em>Section 2.3</em> <a class="iref" href="#rfc.xref.RFC4647.2"> 5.4</a></li>2283 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.RFC4647.3"> 5.4</a></li>2284 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.RFC4647.4"> 5.4</a></li>2278 <li class="indline1"><em>RFC3629</em> <a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b>10.2</b></a></li> 2279 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">7.1</a>, <a class="iref" href="#RFC3864"><b>10.2</b></a></li> 2280 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b>10.2</b></a></li> 2281 <li class="indline1"><em>RFC4647</em> <a class="iref" href="#rfc.xref.RFC4647.1">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">6.4</a>, <a class="iref" href="#RFC4647"><b>10.1</b></a><ul class="ind"> 2282 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC4647.1">6.4</a></li> 2283 <li class="indline1"><em>Section 2.3</em> <a class="iref" href="#rfc.xref.RFC4647.2">6.4</a></li> 2284 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.RFC4647.3">6.4</a></li> 2285 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.RFC4647.4">6.4</a></li> 2285 2286 </ul> 2286 2287 </li> 2287 <li class="indline1"><em>RFC5226</em> <a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b> 9.2</b></a><ul class="ind">2288 <li class="indline1"><em>RFC5226</em> <a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b>10.2</b></a><ul class="ind"> 2288 2289 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a></li> 2289 2290 </ul> 2290 2291 </li> 2291 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b> 9.1</b></a><ul class="ind">2292 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b>10.1</b></a><ul class="ind"> 2292 2293 <li class="indline1"><em>Appendix B.1</em> <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a></li> 2293 2294 </ul> 2294 2295 </li> 2295 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#RFC5322"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li>2296 <li class="indline1"><em>RFC5646</em> <a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b> 9.1</b></a><ul class="ind">2296 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#RFC5322"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li> 2297 <li class="indline1"><em>RFC5646</em> <a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b>10.1</b></a><ul class="ind"> 2297 2298 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a></li> 2298 2299 </ul> -
draft-ietf-httpbis/latest/p4-conditional.html
r964 r966 627 627 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 628 628 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1> 629 <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations from the same requested resource. HTTP/1.1 uses entity-tags630 in the ETag(<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.629 <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations of the same resource. HTTP/1.1 uses entity-tags in the ETag 630 (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator. 631 631 </p> 632 632 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a> … … 642 642 </p> 643 643 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2> 644 <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):644 <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>): 645 645 </p> 646 646 <div id="rfc.figure.u.4"></div> … … 893 893 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 894 894 <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p> 895 <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who896 receives the message.897 </p>898 895 <div id="rfc.iref.e.1"></div> 899 896 <div id="rfc.iref.h.1"></div> 900 897 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 901 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the resource identified by the Effective Request URI. An entity-tag is intended for use as a resource-local898 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local 902 899 identifier for differentiating between representations of the same resource that vary over time or via content negotiation 903 900 (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). … … 1063 1060 <div id="rfc.iref.h.6"></div> 1064 1061 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2> 1065 <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the representation1066 was lastmodified.1062 <p id="rfc.section.6.6.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the representation was last 1063 modified. 1067 1064 </p> 1068 1065 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#header.last-modified" class="smpl">Last-Modified</a> = "Last-Modified" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.last-modified" class="smpl">Last-Modified-v</a> … … 1084 1081 <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible. 1085 1082 </p> 1086 <p id="rfc.section.6.6.p.9">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered1087 to bevalid if the representation has not been modified since the Last-Modified value.1083 <p id="rfc.section.6.6.p.9">The Last-Modified header field value is often used as a cache validator. In simple terms, a cache entry is considered to be 1084 valid if the representation has not been modified since the Last-Modified value. 1088 1085 </p> 1089 1086 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 1450 1447 </li> 1451 1448 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">2.1</a>, <a class="iref" href="#rfc.xref.Part3.2">2.1</a>, <a class="iref" href="#Part3"><b>10.1</b></a><ul class="ind"> 1452 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.1">2.1</a></li>1453 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.2">2.1</a></li>1449 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.1">2.1</a></li> 1450 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part3.2">2.1</a></li> 1454 1451 </ul> 1455 1452 </li> -
draft-ietf-httpbis/latest/p5-range.html
r962 r966 676 676 </li> 677 677 </ul> 678 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise, the response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.678 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request. 679 679 </p> 680 680 <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Ranges">Section 4</a>. … … 690 690 length of the selected resource.) 691 691 </p> 692 <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range entity-header field specifying the current length of the selected resource(see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section 5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.692 <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section 5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type. 693 693 </p> 694 694 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1> … … 710 710 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 711 711 <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to range requests and partial responses.</p> 712 <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who713 receives the message.714 </p>715 712 <div id="rfc.iref.a.1"></div> 716 713 <div id="rfc.iref.h.1"></div> … … 732 729 <div id="rfc.iref.h.2"></div> 733 730 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 734 <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial representation to specify where in the full representation735 the partialbody should be applied.731 <p id="rfc.section.5.2.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload 732 body should be applied. 736 733 </p> 737 734 <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. … … 1351 1348 </li> 1352 1349 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>>: "Clarify entity / representation / variant terminology" 1353 </li>1354 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "Clarify entity / representation / variant terminology"1355 1350 </li> 1356 1351 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "consider removing the 'changes from 2068' sections" -
draft-ietf-httpbis/latest/p6-cache.html
r964 r966 762 762 </p> 763 763 <ul> 764 <li>The presented Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and764 <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and 765 765 </li> 766 766 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 946 946 <li>POST</li> 947 947 </ul> 948 <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.949 </p> 950 <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).951 </p> 952 <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will948 <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 949 </p> 950 <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 951 </p> 952 <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will 953 953 mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 954 954 </p> … … 1012 1012 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1013 1013 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> 1014 <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1015 receives the message.1016 </p>1017 1014 <div id="rfc.iref.a.2"></div> 1018 1015 <div id="rfc.iref.h.2"></div> … … 1257 1254 <div id="rfc.iref.h.4"></div> 1258 1255 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1259 <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section 2.3</a> for further discussion of the freshness model.1256 <p id="rfc.section.3.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section 2.3</a> for further discussion of the freshness model. 1260 1257 </p> 1261 1258 <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after … … 1899 1896 <p id="rfc.section.C.12.p.1">Closed issues: </p> 1900 1897 <ul> 1898 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>>: "Clarify entity / representation / variant terminology" 1899 </li> 1901 1900 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "consider removing the 'changes from 2068' sections" 1902 1901 </li> -
draft-ietf-httpbis/latest/p7-auth.html
r961 r966 613 613 <div id="rfc.iref.s.1"></div> 614 614 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h2> 615 <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section 3.4</a>) containing a challenge applicable to the requestedresource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been615 <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section 3.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been 616 616 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 617 617 already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic … … 622 622 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> 623 623 <p id="rfc.section.2.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The 624 proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 3.2</a>) containing a challenge applicable to the proxy for the requestedresource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.624 proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 3.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 625 625 </p> 626 626 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 655 655 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 656 656 <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters 657 applicable to the proxy for this Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.657 applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 658 658 </p> 659 659 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> … … 683 683 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 684 684 <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s) 685 and parameters applicable to the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.685 and parameters applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 686 686 </p> 687 687 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>
Note: See TracChangeset
for help on using the changeset viewer.