Changeset 1538 for draft-ietf-httpbis/latest
- Timestamp:
- 18/02/12 10:29:16 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/httpbis.abnf
r1494 r1538 61 61 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS transfer-coding ] ) 62 62 URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> 63 Upgrade = *( "," OWS ) pro duct *( OWS "," [ OWS product] )63 Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 64 64 User-Agent = product *( RWS ( product / comment ) ) 65 65 Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) ) … … 181 181 product = token [ "/" product-version ] 182 182 product-version = token 183 protocol = protocol-name [ "/" protocol-version ] 183 184 protocol-name = token 184 185 protocol-version = token -
draft-ietf-httpbis/latest/p1-messaging.html
r1537 r1538 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 0, 2012";462 content: "Expires August 21, 2012"; 463 463 } 464 464 @bottom-right { … … 486 486 <link rel="Chapter" title="3 Message Format" href="#rfc.section.3"> 487 487 <link rel="Chapter" title="4 Message Routing" href="#rfc.section.4"> 488 <link rel="Chapter" title="5 Protocol Parameters" href="#rfc.section.5">488 <link rel="Chapter" title="5 Transfer Codings" href="#rfc.section.5"> 489 489 <link rel="Chapter" title="6 Connections" href="#rfc.section.6"> 490 490 <link rel="Chapter" title="7 Miscellaneous notes that might disappear" href="#rfc.section.7"> … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-1 7">512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-18"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: August 2 0, 2012</td>544 <td class="left">Expires: August 21, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">February 1 7, 2012</td>597 <td class="right">February 18, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on August 2 0, 2012.</p>630 <p>This Internet-Draft will expire on August 21, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 688 688 </ul> 689 689 </li> 690 <li>3.3 <a href="#message.body">Message Body</a></li> 690 <li>3.3 <a href="#message.body">Message Body</a><ul> 691 <li>3.3.1 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 692 <li>3.3.2 <a href="#header.content-length">Content-Length</a></li> 693 <li>3.3.3 <a href="#message.body.length">Message Body Length</a></li> 694 </ul> 695 </li> 691 696 <li>3.4 <a href="#incomplete.messages">Handling Incomplete Messages</a></li> 692 697 <li>3.5 <a href="#message.robustness">Message Parsing Robustness</a></li> … … 700 705 </ul> 701 706 </li> 702 <li>5. <a href="#protocol.parameters">Protocol Parameters</a><ul> 703 <li>5.1 <a href="#transfer.codings">Transfer Codings</a><ul> 704 <li>5.1.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 705 <li>5.1.2 <a href="#compression.codings">Compression Codings</a><ul> 706 <li>5.1.2.1 <a href="#compress.coding">Compress Coding</a></li> 707 <li>5.1.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 708 <li>5.1.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 709 </ul> 710 </li> 711 <li>5.1.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 707 <li>5. <a href="#transfer.codings">Transfer Codings</a><ul> 708 <li>5.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 709 <li>5.2 <a href="#compression.codings">Compression Codings</a><ul> 710 <li>5.2.1 <a href="#compress.coding">Compress Coding</a></li> 711 <li>5.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 712 <li>5.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 712 713 </ul> 713 714 </li> 714 <li>5.2 <a href="#product.tokens">Product Tokens</a></li> 715 <li>5.3 <a href="#quality.values">Quality Values</a></li> 715 <li>5.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 716 <li>5.4 <a href="#header.te">TE</a><ul> 717 <li>5.4.1 <a href="#quality.values">Quality Values</a></li> 718 </ul> 719 </li> 720 <li>5.5 <a href="#header.trailer">Trailer</a></li> 716 721 </ul> 717 722 </li> … … 752 757 <li>8. <a href="#header.field.definitions">Header Field Definitions</a><ul> 753 758 <li>8.1 <a href="#header.connection">Connection</a></li> 754 <li>8.2 <a href="#header.content-length">Content-Length</a></li> 755 <li>8.3 <a href="#header.host">Host</a></li> 756 <li>8.4 <a href="#header.te">TE</a></li> 757 <li>8.5 <a href="#header.trailer">Trailer</a></li> 758 <li>8.6 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 759 <li>8.7 <a href="#header.upgrade">Upgrade</a><ul> 760 <li>8.7.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 759 <li>8.2 <a href="#header.host">Host</a></li> 760 <li>8.3 <a href="#header.upgrade">Upgrade</a><ul> 761 <li>8.3.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 761 762 </ul> 762 763 </li> 763 <li>8. 8 <a href="#header.via">Via</a></li>764 <li>8.4 <a href="#header.via">Via</a></li> 764 765 </ul> 765 766 </li> … … 993 994 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 994 995 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 995 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8. 8</a>) header fields for both connections.996 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.4</a>) header fields for both connections. 996 997 </p> 997 998 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party … … 1291 1292 <a href="#header.fields" class="smpl">field-content</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1292 1293 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1293 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1294 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1294 1295 </p> 1295 1296 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1376 1377 <div id="rule.token.separators"> 1377 1378 <p id="rfc.section.3.2.4.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 1378 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5 .1</a>).1379 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>). 1379 1380 </p> 1380 1381 </div> … … 1454 1455 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1455 1456 </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding 1456 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.6</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message-body length. 1457 </p> 1458 <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header 1459 field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. 1460 </p> 1461 <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing 1457 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>). 1458 </p> 1459 <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1460 <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1461 in the request's header fields, even if the request method does not define any use for a message-body. This allows the request 1462 message framing algorithm to be independent of method semantics. 1463 </p> 1464 <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and 1465 the response status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., 1466 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1467 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length. 1468 </p> 1469 <div id="rfc.iref.t.4"></div> 1470 <div id="rfc.iref.h.6"></div> 1471 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3> 1472 <p id="rfc.section.3.3.1.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs 1473 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.2"><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 1474 are not. 1475 </p> 1476 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1477 </pre><p id="rfc.section.3.3.1.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>. An example is: 1478 </p> 1479 <div id="rfc.figure.u.35"></div><pre class="text"> Transfer-Encoding: chunked 1480 </pre><p id="rfc.section.3.3.1.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. 1481 </p> 1482 <p id="rfc.section.3.3.1.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p> 1483 <p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message-body length. 1484 </p> 1485 <p id="rfc.section.3.3.1.p.8">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header 1486 field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>. 1487 </p> 1488 <div id="rfc.iref.c.6"></div> 1489 <div id="rfc.iref.h.7"></div> 1490 <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h3> 1491 <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other 1492 than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length 1493 indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request 1494 been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload 1495 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 1496 </p> 1497 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1498 </pre><p id="rfc.section.3.3.2.p.3">An example is</p> 1499 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Length: 3495 1500 </pre><p id="rfc.section.3.3.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 1501 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message-body. 1502 </p> 1503 <p id="rfc.section.3.3.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p> 1504 <p id="rfc.section.3.3.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is 1505 an optional field used within the "message/external-body" content-type. 1506 </p> 1507 <p id="rfc.section.3.3.2.p.8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing 1462 1508 a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields 1463 1509 have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing 1464 1510 that decimal value prior to determining the message-body length. 1465 1511 </p> 1466 <p id="rfc.section.3.3.p.6">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1467 <p id="rfc.section.3.3.p.7">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1468 in the request's header fields, even if the request method does not define any use for a message-body. This allows the request 1469 message framing algorithm to be independent of method semantics. 1470 </p> 1471 <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and 1472 the response status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., 1473 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1474 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length. 1475 </p> 1476 <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p> 1477 <p id="rfc.section.3.3.p.10"> </p> 1512 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> 1513 <p id="rfc.section.3.3.3.p.1">The length of the message-body is determined by one of the following (in order of precedence):</p> 1514 <p id="rfc.section.3.3.3.p.2"> </p> 1478 1515 <ol> 1479 1516 <li> … … 1483 1520 </li> 1484 1521 <li> 1485 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5 .1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding1522 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding 1486 1523 indicates the data is complete. 1487 1524 </p> … … 1520 1557 </li> 1521 1558 </ol> 1522 <p id="rfc.section.3.3. p.11">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted1559 <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted 1523 1560 by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility 1524 1561 with HTTP/1.0. 1525 1562 </p> 1526 <p id="rfc.section.3.3. p.12">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).1527 </p> 1528 <p id="rfc.section.3.3. p.13">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,1563 <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required). 1564 </p> 1565 <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding, 1529 1566 since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the 1530 1567 chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in 1531 1568 advance of being called and the server is unable or unwilling to buffer the entire request before processing. 1532 1569 </p> 1533 <p id="rfc.section.3.3. p.14">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such1570 <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such 1534 1571 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1535 1572 </p> … … 1581 1618 </p> 1582 1619 </div> 1583 <div id="rfc.figure.u.3 4"></div><pre>http://www.example.org/where?q=now1620 <div id="rfc.figure.u.38"></div><pre>http://www.example.org/where?q=now 1584 1621 </pre><p id="rfc.section.4.1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1585 1622 lines: 1586 1623 </p> 1587 <div id="rfc.figure.u.3 5"></div><pre class="text2">GET /where?q=now HTTP/1.11624 <div id="rfc.figure.u.39"></div><pre class="text2">GET /where?q=now HTTP/1.1 1588 1625 Host: www.example.org 1589 1626 </pre><p id="rfc.section.4.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path. … … 1599 1636 </p> 1600 1637 </div> 1601 <div id="rfc.figure.u. 36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11638 <div id="rfc.figure.u.40"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1602 1639 </pre><p id="rfc.section.4.1.p.10">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. 1603 1640 </p> … … 1608 1645 </p> 1609 1646 </div> 1610 <div id="rfc.figure.u. 37"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.11647 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1611 1648 </pre><div id="asterix-form"> 1612 1649 <p id="rfc.section.4.1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening … … 1614 1651 </p> 1615 1652 </div> 1616 <div id="rfc.figure.u. 38"></div><pre class="text2">OPTIONS * HTTP/1.11653 <div id="rfc.figure.u.42"></div><pre class="text2">OPTIONS * HTTP/1.1 1617 1654 </pre><p id="rfc.section.4.1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1618 1655 no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server. 1619 1656 </p> 1620 <div id="rfc.figure.u. 39"></div>1657 <div id="rfc.figure.u.43"></div> 1621 1658 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1622 </pre><div id="rfc.figure.u.4 0"></div>1659 </pre><div id="rfc.figure.u.44"></div> 1623 1660 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1624 1661 Host: www.example.org:8001 … … 1649 1686 </p> 1650 1687 <div id="rfc.iref.e.1"></div> 1651 <div id="rfc.iref.t. 4"></div>1688 <div id="rfc.iref.t.5"></div> 1652 1689 <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> 1653 1690 <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 … … 1665 1702 </li> 1666 1703 <li>the octet sequence "://",</li> 1667 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8. 3</a>), and1704 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.2</a>), and 1668 1705 </li> 1669 1706 <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> … … 1673 1710 </p> 1674 1711 <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1675 <div id="rfc.figure.u.4 1"></div>1712 <div id="rfc.figure.u.45"></div> 1676 1713 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1677 1714 Host: www.example.org:8080 … … 1679 1716 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1680 1717 </p> 1681 <div id="rfc.figure.u.4 2"></div>1718 <div id="rfc.figure.u.46"></div> 1682 1719 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1683 1720 Host: www.example.org … … 1695 1732 <p id="rfc.section.4.4.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. 1696 1733 </p> 1697 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1698 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> 1699 <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied 1734 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> 1735 <p id="rfc.section.5.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied 1700 1736 to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the 1701 1737 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1702 1738 </p> 1703 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>1704 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5. 1.2.1</a>1705 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5. 1.2.2</a>1706 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 5. 1.2.3</a>1739 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a> 1740 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5.2.1</a> 1741 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5.2.2</a> 1742 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 5.2.3</a> 1707 1743 / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1708 1744 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> ) 1709 1745 </pre><div id="rule.parameter"> 1710 <p id="rfc.section.5. 1.p.3"> Parameters are in the form of attribute/value pairs.</p>1746 <p id="rfc.section.5.p.3"> Parameters are in the form of attribute/value pairs.</p> 1711 1747 </div> 1712 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1748 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1713 1749 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1714 1750 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1715 </pre><p id="rfc.section.5. 1.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 8.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.6</a>).1716 </p> 1717 <p id="rfc.section.5. 1.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport1751 </pre><p id="rfc.section.5.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 5.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>). 1752 </p> 1753 <p id="rfc.section.5.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1718 1754 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic 1719 1755 of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section 3.3</a>), or the desire to encrypt data over a shared transport. 1720 1756 </p> 1721 <p id="rfc.section.5.1.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1722 </p> 1723 <div id="rfc.iref.c.6"></div> 1757 <p id="rfc.section.5.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1758 </p> 1724 1759 <div id="rfc.iref.c.7"></div> 1725 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3> 1726 <p id="rfc.section.5.1.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 1760 <div id="rfc.iref.c.8"></div> 1761 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2> 1762 <p id="rfc.section.5.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 1727 1763 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 1728 1764 for the recipient to verify that it has received the full message. 1729 1765 </p> 1730 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1766 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1731 1767 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1732 1768 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1748 1784 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1749 1785 <a href="#chunked.encoding" class="smpl">qdtext-nf</a> = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1750 </pre><p id="rfc.section.5.1. 1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended1786 </pre><p id="rfc.section.5.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1751 1787 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1752 1788 </p> 1753 <p id="rfc.section.5.1. 1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field1754 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 8.5</a>).1755 </p> 1756 <p id="rfc.section.5.1. 1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:1789 <p id="rfc.section.5.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1790 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 5.5</a>). 1791 </p> 1792 <p id="rfc.section.5.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: 1757 1793 </p> 1758 1794 <ol> 1759 1795 <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as 1760 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 8.4</a>; or,1796 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 5.4</a>; or, 1761 1797 </li> 1762 1798 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable … … 1766 1802 </li> 1767 1803 </ol> 1768 <p id="rfc.section.5.1. 1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and1804 <p id="rfc.section.5.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and 1769 1805 forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly 1770 1806 infinite buffer on the proxy. 1771 1807 </p> 1772 <p id="rfc.section.5.1. 1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>1773 <div id="rfc.figure.u. 46"></div><pre class="text"> length := 01808 <p id="rfc.section.5.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1809 <div id="rfc.figure.u.50"></div><pre class="text"> length := 0 1774 1810 read chunk-size, chunk-ext (if any) and CRLF 1775 1811 while (chunk-size > 0) { … … 1786 1822 Content-Length := length 1787 1823 Remove "chunked" from Transfer-Encoding 1788 </pre><p id="rfc.section.5.1. 1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.1789 </p> 1790 <p id="rfc.section.5.1. 1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged.1791 </p> 1792 <p id="rfc.section.5.1. 1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting1824 </pre><p id="rfc.section.5.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1825 </p> 1826 <p id="rfc.section.5.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged. 1827 </p> 1828 <p id="rfc.section.5.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting 1793 1829 messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding 1794 1830 applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. 1795 1831 </p> 1796 <h 3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>1797 <p id="rfc.section.5. 1.2.p.1">The codings defined below can be used to compress the payload of a message.</p>1798 <div class="note" id="rfc.section.5. 1.2.p.2">1832 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h2> 1833 <p id="rfc.section.5.2.p.1">The codings defined below can be used to compress the payload of a message.</p> 1834 <div class="note" id="rfc.section.5.2.p.2"> 1799 1835 <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. 1800 1836 Their use here is representative of historical practice, not good design. 1801 1837 </p> 1802 1838 </div> 1803 <div class="note" id="rfc.section.5. 1.2.p.3">1839 <div class="note" id="rfc.section.5.2.p.3"> 1804 1840 <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. 1805 1841 </p> 1806 1842 </div> 1807 <div id="rfc.iref.c.8"></div>1808 1843 <div id="rfc.iref.c.9"></div> 1809 <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h4> 1810 <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1844 <div id="rfc.iref.c.10"></div> 1845 <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h3> 1846 <p id="rfc.section.5.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1811 1847 coding (LZW). 1812 1848 </p> 1813 1849 <div id="rfc.iref.d.2"></div> 1814 <div id="rfc.iref.c.1 0"></div>1815 <h 4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>1816 <p id="rfc.section.5. 1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).1817 </p> 1818 <div class="note" id="rfc.section.5. 1.2.2.p.2">1850 <div id="rfc.iref.c.11"></div> 1851 <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h3> 1852 <p id="rfc.section.5.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>). 1853 </p> 1854 <div class="note" id="rfc.section.5.2.2.p.2"> 1819 1855 <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper. 1820 1856 </p> 1821 1857 </div> 1822 <div id="rfc.iref.g.7 0"></div>1823 <div id="rfc.iref.c.1 1"></div>1824 <h 4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>1825 <p id="rfc.section.5. 1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.1826 </p> 1827 <h 3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>1828 <p id="rfc.section.5. 1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>1829 <p id="rfc.section.5. 1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:1858 <div id="rfc.iref.g.72"></div> 1859 <div id="rfc.iref.c.12"></div> 1860 <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3> 1861 <p id="rfc.section.5.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 1862 </p> 1863 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2> 1864 <p id="rfc.section.5.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p> 1865 <p id="rfc.section.5.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 1830 1866 </p> 1831 1867 <ul> … … 1834 1870 <li>Pointer to specification text</li> 1835 1871 </ul> 1836 <p id="rfc.section.5.1.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.2"><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 5.1.2</a>). 1837 </p> 1838 <p id="rfc.section.5.1.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. 1839 </p> 1840 <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 1841 </p> 1842 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1843 <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 1844 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. 1845 By convention, the products are listed in order of their significance for identifying the application. 1846 </p> 1847 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1848 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1849 </pre><p id="rfc.section.5.2.p.3">Examples:</p> 1850 <div id="rfc.figure.u.48"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1851 Server: Apache/0.8.4 1852 </pre><p id="rfc.section.5.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 1853 </p> 1854 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 1855 <p id="rfc.section.5.3.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 8.4</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.3"><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 1872 <p id="rfc.section.5.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.3"><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 5.2</a>). 1873 </p> 1874 <p id="rfc.section.5.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. 1875 </p> 1876 <p id="rfc.section.5.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 1877 </p> 1878 <div id="rfc.iref.t.6"></div> 1879 <div id="rfc.iref.h.8"></div> 1880 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.te" href="#header.te">TE</a></h2> 1881 <p id="rfc.section.5.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether 1882 or not it is willing to accept trailer fields in a chunked transfer-coding. 1883 </p> 1884 <p id="rfc.section.5.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional 1885 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>). 1886 </p> 1887 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 1888 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 1889 <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) 1890 <a href="#header.te" class="smpl">te-ext</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ] 1891 </pre><p id="rfc.section.5.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 1892 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 1893 </p> 1894 <p id="rfc.section.5.4.p.5">Examples of its use are:</p> 1895 <div id="rfc.figure.u.52"></div><pre class="text"> TE: deflate 1896 TE: 1897 TE: trailers, deflate;q=0.5 1898 </pre><p id="rfc.section.5.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message. 1899 </p> 1900 <p id="rfc.section.5.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 1901 <ol> 1902 <li> 1903 <p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing 1904 to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, 1905 if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, 1906 or that it will attempt to buffer the response on behalf of downstream recipients. 1907 </p> 1908 <p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering 1909 the entire response. 1910 </p> 1911 </li> 1912 <li> 1913 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1914 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 5.4.1</a>, a qvalue of 0 means "not acceptable".) 1915 </p> 1916 </li> 1917 <li> 1918 <p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. 1919 The "chunked" transfer-coding always has a qvalue of 1. 1920 </p> 1921 </li> 1922 </ol> 1923 <p id="rfc.section.5.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 1924 no transfer-coding is always acceptable. 1925 </p> 1926 <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1927 <p id="rfc.section.5.4.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 5.4</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.4"><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 1856 1928 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 1857 1929 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. 1858 1930 </p> 1859 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1931 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1860 1932 / ( "1" [ "." 0*3("0") ] ) 1861 </pre><div class="note" id="rfc.section.5. 3.p.3">1933 </pre><div class="note" id="rfc.section.5.4.1.p.3"> 1862 1934 <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality. 1863 1935 </p> 1864 1936 </div> 1937 <div id="rfc.iref.t.7"></div> 1938 <div id="rfc.iref.h.9"></div> 1939 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1940 <p id="rfc.section.5.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with 1941 chunked transfer-coding. 1942 </p> 1943 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1944 </pre><p id="rfc.section.5.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1945 to know which header fields to expect in the trailer. 1946 </p> 1947 <p id="rfc.section.5.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. 1948 </p> 1949 <p id="rfc.section.5.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: 1950 </p> 1951 <ul> 1952 <li>Transfer-Encoding</li> 1953 <li>Content-Length</li> 1954 <li>Trailer</li> 1955 </ul> 1865 1956 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> 1866 1957 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> … … 1895 1986 </p> 1896 1987 <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 1897 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 4" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.1988 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1898 1989 </p> 1899 1990 <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> … … 1921 2012 </p> 1922 2013 <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> 1923 <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection. 5" title="Connection">Section 8.1</a>.2014 <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>. 1924 2015 </p> 1925 2016 <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects … … 1950 2041 </ul> 1951 2042 <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> 1952 <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 6" title="Connection">Section 8.1</a>).2043 <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 8.1</a>). 1953 2044 </p> 1954 2045 <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> … … 1987 2078 </p> 1988 2079 </div> 1989 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3. 4"><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 5.1</a>).2080 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><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 5</a>). 1990 2081 </p> 1991 2082 <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 2026 2117 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 2027 2118 <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2028 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 5 .1</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.2119 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 5</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. 2029 2120 </p> 2030 2121 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> … … 2036 2127 <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 2037 2128 <ul> 2038 <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 header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2039 </li> 2040 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><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.2129 <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 header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2130 </li> 2131 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><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. 2041 2132 </li> 2042 2133 </ul> … … 2120 2211 <tr> 2121 2212 <td class="left">Connection</td> 2122 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection. 7" title="Connection">Section 8.1</a></td>2213 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a></td> 2123 2214 </tr> 2124 2215 <tr> 2125 2216 <td class="left">Content-Length</td> 2126 <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 8.2</a></td>2217 <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a></td> 2127 2218 </tr> 2128 2219 <tr> 2129 2220 <td class="left">Host</td> 2130 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8. 3</a></td>2221 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.2</a></td> 2131 2222 </tr> 2132 2223 <tr> 2133 2224 <td class="left">TE</td> 2134 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 8.4</a></td>2225 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 5.4</a></td> 2135 2226 </tr> 2136 2227 <tr> 2137 2228 <td class="left">Trailer</td> 2138 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.5</a></td>2229 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 5.5</a></td> 2139 2230 </tr> 2140 2231 <tr> 2141 2232 <td class="left">Transfer-Encoding</td> 2142 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.6</a></td>2233 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 3.3.1</a></td> 2143 2234 </tr> 2144 2235 <tr> 2145 2236 <td class="left">Upgrade</td> 2146 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8. 7</a></td>2237 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.3</a></td> 2147 2238 </tr> 2148 2239 <tr> 2149 2240 <td class="left">Via</td> 2150 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8. 8</a></td>2241 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8.4</a></td> 2151 2242 </tr> 2152 2243 </tbody> 2153 2244 </table> 2154 2245 </div> 2155 <div id="rfc.iref.c.1 2"></div>2156 <div id="rfc.iref.h. 6"></div>2246 <div id="rfc.iref.c.13"></div> 2247 <div id="rfc.iref.h.10"></div> 2157 2248 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 2158 2249 <p id="rfc.section.8.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such … … 2164 2255 </p> 2165 2256 <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p> 2166 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2257 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2167 2258 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2168 2259 </pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove … … 2187 2278 of the response. For example, 2188 2279 </p> 2189 <div id="rfc.figure.u.5 1"></div><pre class="text"> Connection: close2280 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 2190 2281 </pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>) after the current request/response is complete. 2191 2282 </p> … … 2194 2285 <p id="rfc.section.8.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code. 2195 2286 </p> 2196 <div id="rfc.iref.c.13"></div> 2197 <div id="rfc.iref.h.7"></div> 2198 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 2199 <p id="rfc.section.8.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other 2200 than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length 2201 indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request 2202 been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload 2203 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2204 </p> 2205 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 2206 </pre><p id="rfc.section.8.2.p.3">An example is</p> 2207 <div id="rfc.figure.u.53"></div><pre class="text"> Content-Length: 3495 2208 </pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 2209 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message-body. 2210 </p> 2211 <p id="rfc.section.8.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p> 2212 <p id="rfc.section.8.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is 2213 an optional field used within the "message/external-body" content-type. 2214 </p> 2215 <div id="rfc.iref.h.8"></div> 2216 <div id="rfc.iref.h.9"></div> 2217 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.host" href="#header.host">Host</a></h2> 2218 <p id="rfc.section.8.3.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 2287 <div id="rfc.iref.h.11"></div> 2288 <div id="rfc.iref.h.12"></div> 2289 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.host" href="#header.host">Host</a></h2> 2290 <p id="rfc.section.8.2.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 2219 2291 server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the 2220 2292 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line. 2221 2293 </p> 2222 <div id="rfc.figure.u.5 4"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>2223 </pre><p id="rfc.section.8. 3.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then2294 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.81"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 2295 </pre><p id="rfc.section.8.2.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 2224 2296 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 2225 2297 </p> 2226 <p id="rfc.section.8. 3.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p>2227 <div id="rfc.figure.u.5 5"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12298 <p id="rfc.section.8.2.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 2299 <div id="rfc.figure.u.58"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2228 2300 Host: www.example.org 2229 </pre><p id="rfc.section.8. 3.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information2301 </pre><p id="rfc.section.8.2.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information 2230 2302 to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. 2231 2303 </p> 2232 <p id="rfc.section.8. 3.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When2304 <p id="rfc.section.8.2.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When 2233 2305 a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host. 2234 2306 </p> 2235 <p id="rfc.section.8. 3.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to2307 <p id="rfc.section.8.2.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to 2236 2308 poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it 2237 2309 relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared 2238 2310 cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. 2239 2311 </p> 2240 <p id="rfc.section.8. 3.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request2312 <p id="rfc.section.8.2.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request 2241 2313 message that contains more than one Host header field or a Host header field with an invalid field-value. 2242 2314 </p> 2243 <p id="rfc.section.8.3.p.10">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="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host. 2244 </p> 2245 <div id="rfc.iref.t.5"></div> 2246 <div id="rfc.iref.h.10"></div> 2247 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.te" href="#header.te">TE</a></h2> 2248 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether 2249 or not it is willing to accept trailer fields in a chunked transfer-coding. 2250 </p> 2251 <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional 2252 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 2253 </p> 2254 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 2255 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 2256 <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) 2257 <a href="#header.te" class="smpl">te-ext</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ] 2258 </pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 2259 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 2260 </p> 2261 <p id="rfc.section.8.4.p.5">Examples of its use are:</p> 2262 <div id="rfc.figure.u.57"></div><pre class="text"> TE: deflate 2263 TE: 2264 TE: trailers, deflate;q=0.5 2265 </pre><p id="rfc.section.8.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message. 2266 </p> 2267 <p id="rfc.section.8.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 2268 <ol> 2269 <li> 2270 <p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing 2271 to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, 2272 if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, 2273 or that it will attempt to buffer the response on behalf of downstream recipients. 2274 </p> 2275 <p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering 2276 the entire response. 2277 </p> 2278 </li> 2279 <li> 2280 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 2281 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 5.3</a>, a qvalue of 0 means "not acceptable".) 2282 </p> 2283 </li> 2284 <li> 2285 <p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. 2286 The "chunked" transfer-coding always has a qvalue of 1. 2287 </p> 2288 </li> 2289 </ol> 2290 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 2291 no transfer-coding is always acceptable. 2292 </p> 2293 <div id="rfc.iref.t.6"></div> 2294 <div id="rfc.iref.h.11"></div> 2295 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 2296 <p id="rfc.section.8.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with 2297 chunked transfer-coding. 2298 </p> 2299 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2300 </pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 2301 to know which header fields to expect in the trailer. 2302 </p> 2303 <p id="rfc.section.8.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. 2304 </p> 2305 <p id="rfc.section.8.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: 2306 </p> 2307 <ul> 2308 <li>Transfer-Encoding</li> 2309 <li>Content-Length</li> 2310 <li>Trailer</li> 2311 </ul> 2312 <div id="rfc.iref.t.7"></div> 2313 <div id="rfc.iref.h.12"></div> 2314 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2315 <p id="rfc.section.8.6.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs 2316 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.5"><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 2317 are not. 2318 </p> 2319 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.83"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2320 </pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. An example is: 2321 </p> 2322 <div id="rfc.figure.u.60"></div><pre class="text"> Transfer-Encoding: chunked 2323 </pre><p id="rfc.section.8.6.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. 2324 </p> 2325 <p id="rfc.section.8.6.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p> 2315 <p id="rfc.section.8.2.p.10">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="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host. 2316 </p> 2326 2317 <div id="rfc.iref.u.5"></div> 2327 2318 <div id="rfc.iref.h.13"></div> 2328 <h2 id="rfc.section.8. 7"><a href="#rfc.section.8.7">8.7</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2329 <p id="rfc.section.8. 7.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the2319 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2320 <p id="rfc.section.8.3.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2330 2321 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2331 2322 </p> 2332 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.84"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2333 </pre><p id="rfc.section.8.7.p.3">For example,</p> 2334 <div id="rfc.figure.u.62"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2335 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2323 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> 2324 2325 <a href="#header.upgrade" class="smpl">protocol</a> = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>] 2326 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2327 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2328 </pre><p id="rfc.section.8.3.p.3">For example,</p> 2329 <div id="rfc.figure.u.60"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2330 </pre><p id="rfc.section.8.3.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2336 2331 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2337 2332 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2340 2335 the server, possibly according to the nature of the request method or target resource). 2341 2336 </p> 2342 <p id="rfc.section.8. 7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.2337 <p id="rfc.section.8.3.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 2343 2338 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2344 2339 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2345 2340 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2346 2341 </p> 2347 <p id="rfc.section.8. 7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2348 </p> 2349 <p id="rfc.section.8. 7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it2342 <p id="rfc.section.8.3.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2343 </p> 2344 <p id="rfc.section.8.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2350 2345 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2351 2346 </p> 2352 <p id="rfc.section.8. 7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched2347 <p id="rfc.section.8.3.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched 2353 2348 to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2354 2349 </p> 2355 <p id="rfc.section.8. 7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2350 <p id="rfc.section.8.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2356 2351 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2357 2352 below. 2358 2353 </p> 2359 <h3 id="rfc.section.8. 7.1"><a href="#rfc.section.8.7.1">8.7.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>2360 <p id="rfc.section.8. 7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header2361 field. Each registered token is associated with contact information and an optional set of specifications that details how2362 the connection will be processed after it has been upgraded.2363 </p> 2364 <p id="rfc.section.8. 7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:2354 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2355 <p id="rfc.section.8.3.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade 2356 header field. Each registered protocol-name is associated with contact information and an optional set of specifications that 2357 details how the connection will be processed after it has been upgraded. 2358 </p> 2359 <p id="rfc.section.8.3.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules: 2365 2360 </p> 2366 2361 <ol> 2367 <li>A token, once registered, stays registered forever.</li>2362 <li>A protocol-name token, once registered, stays registered forever.</li> 2368 2363 <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. 2369 2364 </li> … … 2372 2367 <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. 2373 2368 </li> 2369 <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration. 2370 </li> 2374 2371 <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. 2375 2372 </li> 2376 <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered. 2377 </li> 2378 <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted. 2373 <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot 2374 be contacted. 2379 2375 </li> 2380 2376 </ol> 2381 2377 <div id="rfc.iref.v.1"></div> 2382 2378 <div id="rfc.iref.h.14"></div> 2383 <h2 id="rfc.section.8. 8"><a href="#rfc.section.8.8">8.8</a> <a id="header.via" href="#header.via">Via</a></h2>2384 <p id="rfc.section.8. 8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server2379 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.via" href="#header.via">Via</a></h2> 2380 <p id="rfc.section.8.4.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server 2385 2381 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email 2386 2382 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 2387 2383 of all senders along the request/response chain. 2388 2384 </p> 2389 <div id="rfc.figure.u.6 3"></div><pre class="inline"><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><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>2385 <div id="rfc.figure.u.61"></div><pre class="inline"><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> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2390 2386 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2391 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a> 2392 <a href="#header.via" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2393 <a href="#header.via" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2387 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> 2394 2388 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 2395 2389 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 2396 </pre><p id="rfc.section.8. 8.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of2390 </pre><p id="rfc.section.8.4.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 2397 2391 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 2398 2392 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 2399 2393 </p> 2400 <p id="rfc.section.8. 8.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port2394 <p id="rfc.section.8.4.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port 2401 2395 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 2402 2396 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 2403 2397 </p> 2404 <p id="rfc.section.8. 8.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.2405 </p> 2406 <p id="rfc.section.8. 8.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header2398 <p id="rfc.section.8.4.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2399 </p> 2400 <p id="rfc.section.8.4.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header 2407 2401 fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2408 2402 </p> 2409 <p id="rfc.section.8. 8.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses2403 <p id="rfc.section.8.4.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 2410 2404 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 2411 2405 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2412 2406 </p> 2413 <div id="rfc.figure.u.6 4"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2414 </pre><p id="rfc.section.8. 8.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,2407 <div id="rfc.figure.u.62"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2408 </pre><p id="rfc.section.8.4.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 2415 2409 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2416 2410 </p> 2417 <p id="rfc.section.8. 8.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.2411 <p id="rfc.section.8.4.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. 2418 2412 For example, 2419 2413 </p> 2420 <div id="rfc.figure.u.6 5"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2421 </pre><p id="rfc.section.8. 8.p.12">could be collapsed to</p>2422 <div id="rfc.figure.u.6 6"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2423 </pre><p id="rfc.section.8. 8.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced2414 <div id="rfc.figure.u.63"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2415 </pre><p id="rfc.section.8.4.p.12">could be collapsed to</p> 2416 <div id="rfc.figure.u.64"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2417 </pre><p id="rfc.section.8.4.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2424 2418 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 2425 2419 </p> … … 2451 2445 <td class="left">http</td> 2452 2446 <td class="left">standard</td> 2453 <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section 8.2</a>2447 <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section 3.3.2</a> 2454 2448 </td> 2455 2449 </tr> … … 2458 2452 <td class="left">http</td> 2459 2453 <td class="left">standard</td> 2460 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8. 3</a>2454 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8.2</a> 2461 2455 </td> 2462 2456 </tr> … … 2465 2459 <td class="left">http</td> 2466 2460 <td class="left">standard</td> 2467 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 8.4</a>2461 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 5.4</a> 2468 2462 </td> 2469 2463 </tr> … … 2472 2466 <td class="left">http</td> 2473 2467 <td class="left">standard</td> 2474 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 8.5</a>2468 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 5.5</a> 2475 2469 </td> 2476 2470 </tr> … … 2479 2473 <td class="left">http</td> 2480 2474 <td class="left">standard</td> 2481 <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.6</a>2475 <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 3.3.1</a> 2482 2476 </td> 2483 2477 </tr> … … 2486 2480 <td class="left">http</td> 2487 2481 <td class="left">standard</td> 2488 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8. 7</a>2482 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8.3</a> 2489 2483 </td> 2490 2484 </tr> … … 2493 2487 <td class="left">http</td> 2494 2488 <td class="left">standard</td> 2495 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8. 8</a>2489 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8.4</a> 2496 2490 </td> 2497 2491 </tr> … … 2642 2636 </dl> 2643 2637 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2> 2644 <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 5. 1.3</a> of this document.2638 <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 5.3</a> of this document. 2645 2639 </p> 2646 2640 <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registrations below: … … 2660 2654 <td class="left">chunked</td> 2661 2655 <td class="left">Transfer in a series of chunks</td> 2662 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1 .1</a>2656 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a> 2663 2657 </td> 2664 2658 </tr> … … 2666 2660 <td class="left">compress</td> 2667 2661 <td class="left">UNIX "compress" program method</td> 2668 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 5. 1.2.1</a>2662 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 5.2.1</a> 2669 2663 </td> 2670 2664 </tr> … … 2673 2667 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 2674 2668 </td> 2675 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 5. 1.2.2</a>2669 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 5.2.2</a> 2676 2670 </td> 2677 2671 </tr> … … 2679 2673 <td class="left">gzip</td> 2680 2674 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 2681 <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section 5. 1.2.3</a>2675 <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section 5.2.3</a> 2682 2676 </td> 2683 2677 </tr> … … 2686 2680 </div> 2687 2681 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2688 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8. 7.1</a> of this document.2682 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.3.1</a> of this document. 2689 2683 </p> 2690 2684 <p id="rfc.section.9.5.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> shall be updated with the registration below: … … 3037 3031 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3038 3032 <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 3039 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 8. 3</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.3033 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 8.2</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1. 3040 3034 </p> 3041 3035 <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 3081 3075 <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) 3082 3076 </p> 3083 <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5 .1</a>)3077 <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5</a>) 3084 3078 </p> 3085 3079 <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk … … 3087 3081 </p> 3088 3082 <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore 3089 disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1 .1</a>)3083 disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) 3090 3084 </p> 3091 3085 <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. … … 3098 3092 <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 8.1</a>) 3099 3093 </p> 3100 <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8. 7</a>)3094 <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8.3</a>) 3101 3095 </p> 3102 3096 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3103 <div id="rfc.figure.u.6 7"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3097 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3104 3098 3105 3099 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF … … 3131 3125 3132 3126 <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in [RFC3986], Section 4.1> 3133 <a href="#header.upgrade" class="smpl">Upgrade</a> = *( "," OWS ) pro duct *( OWS "," [ OWS product] )3127 <a href="#header.upgrade" class="smpl">Upgrade</a> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 3134 3128 3135 3129 <a href="#header.via" class="smpl">Via</a> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] … … 3173 3167 <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in [RFC3986], Section 3.3> 3174 3168 <a href="#uri" class="smpl">port</a> = <port, defined in [RFC3986], Section 3.2.3> 3175 <a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ] 3176 <a href="#product.tokens" class="smpl">product-version</a> = token 3177 <a href="#header.via" class="smpl">protocol-name</a> = token 3178 <a href="#header.via" class="smpl">protocol-version</a> = token 3169 <a href="#header.upgrade" class="smpl">protocol</a> = protocol-name [ "/" protocol-version ] 3170 <a href="#header.upgrade" class="smpl">protocol-name</a> = token 3171 <a href="#header.upgrade" class="smpl">protocol-version</a> = token 3179 3172 <a href="#header.via" class="smpl">pseudonym</a> = token 3180 3173 … … 3219 3212 3220 3213 <a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string 3221 </pre> <div id="rfc.figure.u.6 8"></div>3214 </pre> <div id="rfc.figure.u.66"></div> 3222 3215 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3223 3216 ; Connection defined but not used … … 3636 3629 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3637 3630 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3638 <li>chunked (Coding Format) <a href="#rfc.iref.c. 6">5.1.1</a></li>3631 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">5.1</a></li> 3639 3632 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3640 3633 <li>Coding Format 3641 3634 <ul> 3642 <li>chunked <a href="#rfc.iref.c. 7">5.1.1</a></li>3643 <li>compress <a href="#rfc.iref.c. 9">5.1.2.1</a></li>3644 <li>deflate <a href="#rfc.iref.c.1 0">5.1.2.2</a></li>3645 <li>gzip <a href="#rfc.iref.c.1 1">5.1.2.3</a></li>3635 <li>chunked <a href="#rfc.iref.c.8">5.1</a></li> 3636 <li>compress <a href="#rfc.iref.c.10">5.2.1</a></li> 3637 <li>deflate <a href="#rfc.iref.c.11">5.2.2</a></li> 3638 <li>gzip <a href="#rfc.iref.c.12">5.2.3</a></li> 3646 3639 </ul> 3647 3640 </li> 3648 <li>compress (Coding Format) <a href="#rfc.iref.c. 8">5.1.2.1</a></li>3641 <li>compress (Coding Format) <a href="#rfc.iref.c.9">5.2.1</a></li> 3649 3642 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3650 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4"> 6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3651 <li>Content-Length header field <a href="#rfc. xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>3643 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">5.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.c.13"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.3</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3644 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3652 3645 </ul> 3653 3646 </li> 3654 3647 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3655 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5. 1.2.2</a></li>3648 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5.2.2</a></li> 3656 3649 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3657 3650 </ul> … … 3667 3660 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3668 3661 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3669 <li><tt>attribute</tt> <a href="#rfc.iref.g.5 5"><b>5.1</b></a></li>3662 <li><tt>attribute</tt> <a href="#rfc.iref.g.57"><b>5</b></a></li> 3670 3663 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3671 3664 <li><tt>BWS</tt> <a href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 3672 <li><tt>chunk</tt> <a href="#rfc.iref.g.6 0"><b>5.1.1</b></a></li>3673 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.6 6"><b>5.1.1</b></a></li>3674 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.6 3"><b>5.1.1</b></a></li>3675 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.6 4"><b>5.1.1</b></a></li>3676 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.6 5"><b>5.1.1</b></a></li>3677 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.6 1"><b>5.1.1</b></a></li>3678 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g. 59"><b>5.1.1</b></a></li>3665 <li><tt>chunk</tt> <a href="#rfc.iref.g.62"><b>5.1</b></a></li> 3666 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.68"><b>5.1</b></a></li> 3667 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.65"><b>5.1</b></a></li> 3668 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.66"><b>5.1</b></a></li> 3669 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.67"><b>5.1</b></a></li> 3670 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.63"><b>5.1</b></a></li> 3671 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.61"><b>5.1</b></a></li> 3679 3672 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.4</b></a></li> 3680 <li><tt>Connection</tt> <a href="#rfc.iref.g.7 4"><b>8.1</b></a></li>3681 <li><tt>connection-token</tt> <a href="#rfc.iref.g. 75"><b>8.1</b></a></li>3682 <li><tt>Content-Length</tt> <a href="#rfc.iref.g. 76"><b>8.2</b></a></li>3673 <li><tt>Connection</tt> <a href="#rfc.iref.g.79"><b>8.1</b></a></li> 3674 <li><tt>connection-token</tt> <a href="#rfc.iref.g.80"><b>8.1</b></a></li> 3675 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.53"><b>3.3.2</b></a></li> 3683 3676 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3684 3677 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3685 3678 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3686 3679 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3687 <li><tt>date2</tt> <a href="#rfc.iref.g.5 7"><b>5.1</b></a></li>3688 <li><tt>date3</tt> <a href="#rfc.iref.g. 58"><b>5.1</b></a></li>3680 <li><tt>date2</tt> <a href="#rfc.iref.g.59"><b>5</b></a></li> 3681 <li><tt>date3</tt> <a href="#rfc.iref.g.60"><b>5</b></a></li> 3689 3682 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3690 3683 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> … … 3694 3687 <li><tt>header-field</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3695 3688 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3696 <li><tt>Host</tt> <a href="#rfc.iref.g. 77"><b>8.3</b></a></li>3689 <li><tt>Host</tt> <a href="#rfc.iref.g.81"><b>8.2</b></a></li> 3697 3690 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3698 3691 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.25"><b>3</b></a></li> … … 3701 3694 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3702 3695 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2.7.2</b></a></li> 3703 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.6 2"><b>5.1.1</b></a></li>3696 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.64"><b>5.1</b></a></li> 3704 3697 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3705 3698 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> … … 3710 3703 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3711 3704 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3712 <li><tt>product</tt> <a href="#rfc.iref.g.71"><b>5.2</b></a></li> 3713 <li><tt>product-version</tt> <a href="#rfc.iref.g.72"><b>5.2</b></a></li> 3714 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>8.8</b></a></li> 3715 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>8.8</b></a></li> 3716 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>8.8</b></a></li> 3705 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.85"><b>8.4</b></a></li> 3706 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.86"><b>8.4</b></a></li> 3707 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.88"><b>8.4</b></a></li> 3717 3708 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3718 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g. 69"><b>5.1.1</b></a></li>3709 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.71"><b>5.1</b></a></li> 3719 3710 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3720 3711 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.4</b></a></li> 3721 3712 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.4</b></a></li> 3722 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g. 68"><b>5.1.1</b></a></li>3713 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.70"><b>5.1</b></a></li> 3723 3714 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.4</b></a></li> 3724 <li><tt>qvalue</tt> <a href="#rfc.iref.g.7 3"><b>5.3</b></a></li>3715 <li><tt>qvalue</tt> <a href="#rfc.iref.g.77"><b>5.4.1</b></a></li> 3725 3716 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li> 3726 <li><tt>received-by</tt> <a href="#rfc.iref.g.8 9"><b>8.8</b></a></li>3727 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.8 6"><b>8.8</b></a></li>3717 <li><tt>received-by</tt> <a href="#rfc.iref.g.87"><b>8.4</b></a></li> 3718 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.84"><b>8.4</b></a></li> 3728 3719 <li><tt>Request-Line</tt> <a href="#rfc.iref.g.27"><b>3.1.1</b></a></li> 3729 3720 <li><tt>request-target</tt> <a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li> … … 3734 3725 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li> 3735 3726 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3736 <li><tt>t-codings</tt> <a href="#rfc.iref.g.7 9"><b>8.4</b></a></li>3727 <li><tt>t-codings</tt> <a href="#rfc.iref.g.74"><b>5.4</b></a></li> 3737 3728 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3738 <li><tt>TE</tt> <a href="#rfc.iref.g.7 8"><b>8.4</b></a></li>3739 <li><tt>te-ext</tt> <a href="#rfc.iref.g. 81"><b>8.4</b></a></li>3740 <li><tt>te-params</tt> <a href="#rfc.iref.g. 80"><b>8.4</b></a></li>3729 <li><tt>TE</tt> <a href="#rfc.iref.g.73"><b>5.4</b></a></li> 3730 <li><tt>te-ext</tt> <a href="#rfc.iref.g.76"><b>5.4</b></a></li> 3731 <li><tt>te-params</tt> <a href="#rfc.iref.g.75"><b>5.4</b></a></li> 3741 3732 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3742 <li><tt>Trailer</tt> <a href="#rfc.iref.g. 82"><b>8.5</b></a></li>3743 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.6 7"><b>5.1.1</b></a></li>3744 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.5 2"><b>5.1</b></a></li>3745 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g. 83"><b>8.6</b></a></li>3746 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.5 3"><b>5.1</b></a></li>3747 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.5 4"><b>5.1</b></a></li>3748 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.8 4"><b>8.7</b></a></li>3733 <li><tt>Trailer</tt> <a href="#rfc.iref.g.78"><b>5.5</b></a></li> 3734 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.69"><b>5.1</b></a></li> 3735 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.54"><b>5</b></a></li> 3736 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.52"><b>3.3.1</b></a></li> 3737 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.55"><b>5</b></a></li> 3738 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.56"><b>5</b></a></li> 3739 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.82"><b>8.3</b></a></li> 3749 3740 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3750 3741 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3751 <li><tt>value</tt> <a href="#rfc.iref.g.5 6"><b>5.1</b></a></li>3742 <li><tt>value</tt> <a href="#rfc.iref.g.58"><b>5</b></a></li> 3752 3743 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3753 <li><tt>Via</tt> <a href="#rfc.iref.g.8 5"><b>8.8</b></a></li>3744 <li><tt>Via</tt> <a href="#rfc.iref.g.83"><b>8.4</b></a></li> 3754 3745 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2.4</b></a></li> 3755 3746 </ul> 3756 3747 </li> 3757 <li>gzip (Coding Format) <a href="#rfc.iref.g.7 0">5.1.2.3</a></li>3748 <li>gzip (Coding Format) <a href="#rfc.iref.g.72">5.2.3</a></li> 3758 3749 </ul> 3759 3750 </li> … … 3762 3753 <li>Header Fields 3763 3754 <ul> 3764 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4"> 6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3765 <li>Content-Length <a href="#rfc. xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>3766 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h. 9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>3767 <li>TE <a href="#rfc.xref.header.te.1">5 .1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>3768 <li>Trailer <a href="#rfc.xref.header.trailer.1">5.1 .1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>3769 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc. xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>3770 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8. 7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3771 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8. 8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3755 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">5.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.h.10"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.3</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3756 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3757 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.12"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3758 <li>TE <a href="#rfc.xref.header.te.1">5</a>, <a href="#rfc.xref.header.te.2">5.1</a>, <a href="#rfc.iref.h.8"><b>5.4</b></a>, <a href="#rfc.xref.header.te.3">5.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3759 <li>Trailer <a href="#rfc.xref.header.trailer.1">5.1</a>, <a href="#rfc.iref.h.9"><b>5.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3760 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">5</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3761 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3762 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3772 3763 </ul> 3773 3764 </li> 3774 3765 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3775 3766 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3776 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h. 8"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>3767 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.11"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3777 3768 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3778 3769 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3814 3805 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3815 3806 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3816 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8. 7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3807 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.3</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3817 3808 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3818 3809 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> … … 3823 3814 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3824 3815 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3825 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.16">8. 7</a></li>3816 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.16">8.3</a></li> 3826 3817 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.18">10.6</a></li> 3827 3818 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.17">10.6</a></li> 3828 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li>3829 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>3819 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3820 <li><em>Section 10.3</em> <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3830 3821 </ul> 3831 3822 </li> 3832 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2"> 5.1.3</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.6</a>, <a href="#Part3"><b>12.1</b></a><ul>3833 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2"> 5.1.3</a>, <a href="#rfc.xref.Part3.5">8.6</a></li>3834 <li><em>Section 5</em> <a href="#rfc.xref.Part3. 3">5.3</a></li>3823 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">5.4.1</a>, <a href="#rfc.xref.Part3.5">6.1.3.2</a>, <a href="#Part3"><b>12.1</b></a><ul> 3824 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">5.3</a></li> 3825 <li><em>Section 5</em> <a href="#rfc.xref.Part3.4">5.4.1</a></li> 3835 3826 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li> 3836 3827 </ul> … … 3854 3845 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li> 3855 3846 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li> 3856 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">5. 1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>3857 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">5. 1.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>3858 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">5. 1.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>3859 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5 .1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>3860 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">5 .1</a></li>3847 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">5.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li> 3848 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">5.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li> 3849 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">5.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li> 3850 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5</a>, <a href="#RFC2045"><b>12.2</b></a><ul> 3851 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">5</a></li> 3861 3852 </ul> 3862 3853 </li> … … 3899 3890 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li> 3900 3891 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li> 3901 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5. 1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>3902 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5. 1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li>3892 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul> 3893 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a></li> 3903 3894 </ul> 3904 3895 </li> … … 3907 3898 </ul> 3908 3899 </li> 3909 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8. 8</a>, <a href="#RFC5322"><b>12.2</b></a><ul>3910 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">8. 8</a></li>3900 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.4</a>, <a href="#RFC5322"><b>12.2</b></a><ul> 3901 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">8.4</a></li> 3911 3902 </ul> 3912 3903 </li> … … 3922 3913 </li> 3923 3914 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3924 <li>target resource <a href="#rfc.iref.t. 4"><b>4.3</b></a></li>3925 <li>TE header field <a href="#rfc.xref.header.te.1">5 .1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>3915 <li>target resource <a href="#rfc.iref.t.5"><b>4.3</b></a></li> 3916 <li>TE header field <a href="#rfc.xref.header.te.1">5</a>, <a href="#rfc.xref.header.te.2">5.1</a>, <a href="#rfc.iref.t.6"><b>5.4</b></a>, <a href="#rfc.xref.header.te.3">5.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3926 3917 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> 3927 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">5.1 .1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>3928 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc. xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>3918 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">5.1</a>, <a href="#rfc.iref.t.7"><b>5.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3919 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">5</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3929 3920 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3930 3921 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li> … … 3933 3924 </li> 3934 3925 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3935 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8. 7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3926 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3936 3927 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3937 3928 <li>URI scheme … … 3946 3937 </li> 3947 3938 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3948 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8. 8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3939 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3949 3940 </ul> 3950 3941 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1537 r1538 1559 1559 The message-body differs from the payload body only when a transfer-coding 1560 1560 has been applied, as indicated by the Transfer-Encoding header field 1561 (<xref target="header.transfer-encoding"/>). If more than one 1561 (<xref target="header.transfer-encoding"/>). 1562 </t> 1563 <t> 1564 The rules for when a message-body is allowed in a message differ for 1565 requests and responses. 1566 </t> 1567 <t> 1568 The presence of a message-body in a request is signaled by the 1569 inclusion of a Content-Length or Transfer-Encoding header field in 1570 the request's header fields, even if the request method does not 1571 define any use for a message-body. This allows the request 1572 message framing algorithm to be independent of method semantics. 1573 </t> 1574 <t> 1575 For response messages, whether or not a message-body is included with 1576 a message is dependent on both the request method and the response 1577 status code (<xref target="status.code"/>). 1578 Responses to the HEAD request method never include a message-body 1579 because the associated response header fields (e.g., Transfer-Encoding, 1580 Content-Length, etc.) only indicate what their values would have been 1581 if the request method had been GET. All 1xx (Informational), 204 (No Content), 1582 and 304 (Not Modified) responses &MUST-NOT; include a message-body. 1583 All other responses do include a message-body, although the body 1584 &MAY; be of zero length. 1585 </t> 1586 1587 <section title="Transfer-Encoding" anchor="header.transfer-encoding"> 1588 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/> 1589 <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/> 1590 <x:anchor-alias value="Transfer-Encoding"/> 1591 <t> 1592 The "Transfer-Encoding" header field indicates what transfer-codings 1593 (if any) have been applied to the message body. It differs from 1594 Content-Encoding (&content-codings;) in that transfer-codings are a property 1595 of the message (and therefore are removed by intermediaries), whereas 1596 content-codings are not. 1597 </t> 1598 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> 1599 <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref> 1600 </artwork></figure> 1601 <t> 1602 Transfer-codings are defined in <xref target="transfer.codings"/>. An example is: 1603 </t> 1604 <figure><artwork type="example"> 1605 Transfer-Encoding: chunked 1606 </artwork></figure> 1607 <t> 1608 If multiple encodings have been applied to a representation, the transfer-codings 1609 &MUST; be listed in the order in which they were applied. 1610 Additional information about the encoding parameters &MAY; be provided 1611 by other header fields not defined by this specification. 1612 </t> 1613 <t> 1614 Many older HTTP/1.0 applications do not understand the Transfer-Encoding 1615 header field. 1616 </t> 1617 <t> 1618 If more than one 1562 1619 Transfer-Encoding header field is present in a message, the multiple 1563 1620 field-values &MUST; be combined into one field-value, according to the … … 1572 1629 any implementation along the request/response chain under the constraints 1573 1630 found in <xref target="transfer.codings"/>. 1631 </t> 1632 </section> 1633 1634 <section title="Content-Length" anchor="header.content-length"> 1635 <iref primary="true" item="Content-Length header field" x:for-anchor=""/> 1636 <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/> 1637 <x:anchor-alias value="Content-Length"/> 1638 <t> 1639 The "Content-Length" header field indicates the size of the 1640 message-body, in decimal number of octets, for any message other than 1641 a response to a HEAD request or a response with a status code of 304. 1642 In the case of a response to a HEAD request, Content-Length indicates 1643 the size of the payload body (not including any potential transfer-coding) 1644 that would have been sent had the request been a GET. 1645 In the case of a 304 (Not Modified) response to a GET request, 1646 Content-Length indicates the size of the payload body (not including 1647 any potential transfer-coding) that would have been sent in a 200 (OK) 1648 response. 1649 </t> 1650 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> 1651 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref> 1652 </artwork></figure> 1653 <t> 1654 An example is 1655 </t> 1656 <figure><artwork type="example"> 1657 Content-Length: 3495 1658 </artwork></figure> 1659 <t> 1660 Implementations &SHOULD; use this field to indicate the message-body 1661 length when no transfer-coding is being applied and the 1662 payload's body length can be determined prior to being transferred. 1663 <xref target="message.body"/> describes how recipients determine the length 1664 of a message-body. 1665 </t> 1666 <t> 1667 Any Content-Length greater than or equal to zero is a valid value. 1668 </t> 1669 <t> 1670 Note that the use of this field in HTTP is significantly different from 1671 the corresponding definition in MIME, where it is an optional field 1672 used within the "message/external-body" content-type. 1574 1673 </t> 1575 1674 <t> … … 1585 1684 length. 1586 1685 </t> 1587 <t> 1588 The rules for when a message-body is allowed in a message differ for 1589 requests and responses. 1590 </t> 1591 <t> 1592 The presence of a message-body in a request is signaled by the 1593 inclusion of a Content-Length or Transfer-Encoding header field in 1594 the request's header fields, even if the request method does not 1595 define any use for a message-body. This allows the request 1596 message framing algorithm to be independent of method semantics. 1597 </t> 1598 <t> 1599 For response messages, whether or not a message-body is included with 1600 a message is dependent on both the request method and the response 1601 status code (<xref target="status.code"/>). 1602 Responses to the HEAD request method never include a message-body 1603 because the associated response header fields (e.g., Transfer-Encoding, 1604 Content-Length, etc.) only indicate what their values would have been 1605 if the request method had been GET. All 1xx (Informational), 204 (No Content), 1606 and 304 (Not Modified) responses &MUST-NOT; include a message-body. 1607 All other responses do include a message-body, although the body 1608 &MAY; be of zero length. 1609 </t> 1686 </section> 1687 1688 <section title="Message Body Length" anchor="message.body.length"> 1610 1689 <t> 1611 1690 The length of the message-body is determined by one of the following … … 1717 1796 </t> 1718 1797 </section> 1798 </section> 1719 1799 1720 1800 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> … … 2051 2131 </section> 2052 2132 2053 2054 <section title="Protocol Parameters" anchor="protocol.parameters">2055 2056 2133 <section title="Transfer Codings" anchor="transfer.codings"> 2057 2134 <x:anchor-alias value="transfer-coding"/> … … 2313 2390 </t> 2314 2391 </section> 2315 </section> 2316 2317 <section title="Product Tokens" anchor="product.tokens"> 2318 <x:anchor-alias value="product"/> 2319 <x:anchor-alias value="product-version"/> 2320 <t> 2321 Product tokens are used to allow communicating applications to 2322 identify themselves by software name and version. Most fields using 2323 product tokens also allow sub-products which form a significant part 2324 of the application to be listed, separated by whitespace. By 2325 convention, the products are listed in order of their significance 2326 for identifying the application. 2327 </t> 2328 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> 2329 <x:ref>product</x:ref> = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>] 2330 <x:ref>product-version</x:ref> = <x:ref>token</x:ref> 2392 2393 <section title="TE" anchor="header.te"> 2394 <iref primary="true" item="TE header field" x:for-anchor=""/> 2395 <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/> 2396 <x:anchor-alias value="TE"/> 2397 <x:anchor-alias value="t-codings"/> 2398 <x:anchor-alias value="te-params"/> 2399 <x:anchor-alias value="te-ext"/> 2400 <t> 2401 The "TE" header field indicates what extension transfer-codings 2402 the client is willing to accept in the response, and whether or not it is 2403 willing to accept trailer fields in a chunked transfer-coding. 2404 </t> 2405 <t> 2406 Its value consists of the keyword "trailers" and/or a comma-separated 2407 list of extension transfer-coding names with optional accept 2408 parameters (as described in <xref target="transfer.codings"/>). 2409 </t> 2410 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/> 2411 <x:ref>TE</x:ref> = #<x:ref>t-codings</x:ref> 2412 <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] ) 2413 <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> ) 2414 <x:ref>te-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ] 2331 2415 </artwork></figure> 2332 2416 <t> 2333 Examples: 2417 The presence of the keyword "trailers" indicates that the client is 2418 willing to accept trailer fields in a chunked transfer-coding, as 2419 defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with 2420 transfer-coding values even though it does not itself represent a 2421 transfer-coding. 2422 </t> 2423 <t> 2424 Examples of its use are: 2334 2425 </t> 2335 2426 <figure><artwork type="example"> 2336 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2337 Server: Apache/0.8.4 2427 TE: deflate 2428 TE: 2429 TE: trailers, deflate;q=0.5 2338 2430 </artwork></figure> 2339 2431 <t> 2340 Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be 2341 used for advertising or other non-essential information. Although any 2342 token octet &MAY; appear in a product-version, this token &SHOULD; 2343 only be used for a version identifier (i.e., successive versions of 2344 the same product &SHOULD; only differ in the product-version portion of 2345 the product value). 2346 </t> 2347 </section> 2432 The TE header field only applies to the immediate connection. 2433 Therefore, the keyword &MUST; be supplied within a Connection header 2434 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. 2435 </t> 2436 <t> 2437 A server tests whether a transfer-coding is acceptable, according to 2438 a TE field, using these rules: 2439 <list style="numbers"> 2440 <x:lt> 2441 <t>The "chunked" transfer-coding is always acceptable. If the 2442 keyword "trailers" is listed, the client indicates that it is 2443 willing to accept trailer fields in the chunked response on 2444 behalf of itself and any downstream clients. The implication is 2445 that, if given, the client is stating that either all 2446 downstream clients are willing to accept trailer fields in the 2447 forwarded response, or that it will attempt to buffer the 2448 response on behalf of downstream recipients. 2449 </t><t> 2450 <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a 2451 chunked response such that a client can be assured of buffering 2452 the entire response.</t> 2453 </x:lt> 2454 <x:lt> 2455 <t>If the transfer-coding being tested is one of the transfer-codings 2456 listed in the TE field, then it is acceptable unless it 2457 is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a 2458 qvalue of 0 means "not acceptable".)</t> 2459 </x:lt> 2460 <x:lt> 2461 <t>If multiple transfer-codings are acceptable, then the 2462 acceptable transfer-coding with the highest non-zero qvalue is 2463 preferred. The "chunked" transfer-coding always has a qvalue 2464 of 1.</t> 2465 </x:lt> 2466 </list> 2467 </t> 2468 <t> 2469 If the TE field-value is empty or if no TE field is present, the only 2470 acceptable transfer-coding is "chunked". A message with no transfer-coding is 2471 always acceptable. 2472 </t> 2348 2473 2349 2474 <section title="Quality Values" anchor="quality.values"> … … 2372 2497 </x:note> 2373 2498 </section> 2374 2499 </section> 2500 2501 <section title="Trailer" anchor="header.trailer"> 2502 <iref primary="true" item="Trailer header field" x:for-anchor=""/> 2503 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/> 2504 <x:anchor-alias value="Trailer"/> 2505 <t> 2506 The "Trailer" header field indicates that the given set of 2507 header fields is present in the trailer of a message encoded with 2508 chunked transfer-coding. 2509 </t> 2510 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> 2511 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref> 2512 </artwork></figure> 2513 <t> 2514 An HTTP/1.1 message &SHOULD; include a Trailer header field in a 2515 message using chunked transfer-coding with a non-empty trailer. Doing 2516 so allows the recipient to know which header fields to expect in the 2517 trailer. 2518 </t> 2519 <t> 2520 If no Trailer header field is present, the trailer &SHOULD-NOT; include 2521 any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of 2522 trailer fields in a "chunked" transfer-coding. 2523 </t> 2524 <t> 2525 Message header fields listed in the Trailer header field &MUST-NOT; 2526 include the following header fields: 2527 <list style="symbols"> 2528 <t>Transfer-Encoding</t> 2529 <t>Content-Length</t> 2530 <t>Trailer</t> 2531 </list> 2532 </t> 2533 </section> 2375 2534 </section> 2376 2535 … … 2998 3157 </section> 2999 3158 3000 <section title="Content-Length" anchor="header.content-length">3001 <iref primary="true" item="Content-Length header field" x:for-anchor=""/>3002 <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/>3003 <x:anchor-alias value="Content-Length"/>3004 <t>3005 The "Content-Length" header field indicates the size of the3006 message-body, in decimal number of octets, for any message other than3007 a response to a HEAD request or a response with a status code of 304.3008 In the case of a response to a HEAD request, Content-Length indicates3009 the size of the payload body (not including any potential transfer-coding)3010 that would have been sent had the request been a GET.3011 In the case of a 304 (Not Modified) response to a GET request,3012 Content-Length indicates the size of the payload body (not including3013 any potential transfer-coding) that would have been sent in a 200 (OK)3014 response.3015 </t>3016 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>3017 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>3018 </artwork></figure>3019 <t>3020 An example is3021 </t>3022 <figure><artwork type="example">3023 Content-Length: 34953024 </artwork></figure>3025 <t>3026 Implementations &SHOULD; use this field to indicate the message-body3027 length when no transfer-coding is being applied and the3028 payload's body length can be determined prior to being transferred.3029 <xref target="message.body"/> describes how recipients determine the length3030 of a message-body.3031 </t>3032 <t>3033 Any Content-Length greater than or equal to zero is a valid value.3034 </t>3035 <t>3036 Note that the use of this field in HTTP is significantly different from3037 the corresponding definition in MIME, where it is an optional field3038 used within the "message/external-body" content-type.3039 </t>3040 </section>3041 3042 3159 <section title="Host" anchor="header.host"> 3043 3160 <iref primary="true" item="Host header field" x:for-anchor=""/> … … 3109 3226 </section> 3110 3227 3111 <section title="TE" anchor="header.te">3112 <iref primary="true" item="TE header field" x:for-anchor=""/>3113 <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/>3114 <x:anchor-alias value="TE"/>3115 <x:anchor-alias value="t-codings"/>3116 <x:anchor-alias value="te-params"/>3117 <x:anchor-alias value="te-ext"/>3118 <t>3119 The "TE" header field indicates what extension transfer-codings3120 the client is willing to accept in the response, and whether or not it is3121 willing to accept trailer fields in a chunked transfer-coding.3122 </t>3123 <t>3124 Its value consists of the keyword "trailers" and/or a comma-separated3125 list of extension transfer-coding names with optional accept3126 parameters (as described in <xref target="transfer.codings"/>).3127 </t>3128 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/>3129 <x:ref>TE</x:ref> = #<x:ref>t-codings</x:ref>3130 <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] )3131 <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> )3132 <x:ref>te-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]3133 </artwork></figure>3134 <t>3135 The presence of the keyword "trailers" indicates that the client is3136 willing to accept trailer fields in a chunked transfer-coding, as3137 defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with3138 transfer-coding values even though it does not itself represent a3139 transfer-coding.3140 </t>3141 <t>3142 Examples of its use are:3143 </t>3144 <figure><artwork type="example">3145 TE: deflate3146 TE:3147 TE: trailers, deflate;q=0.53148 </artwork></figure>3149 <t>3150 The TE header field only applies to the immediate connection.3151 Therefore, the keyword &MUST; be supplied within a Connection header3152 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.3153 </t>3154 <t>3155 A server tests whether a transfer-coding is acceptable, according to3156 a TE field, using these rules:3157 <list style="numbers">3158 <x:lt>3159 <t>The "chunked" transfer-coding is always acceptable. If the3160 keyword "trailers" is listed, the client indicates that it is3161 willing to accept trailer fields in the chunked response on3162 behalf of itself and any downstream clients. The implication is3163 that, if given, the client is stating that either all3164 downstream clients are willing to accept trailer fields in the3165 forwarded response, or that it will attempt to buffer the3166 response on behalf of downstream recipients.3167 </t><t>3168 <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a3169 chunked response such that a client can be assured of buffering3170 the entire response.</t>3171 </x:lt>3172 <x:lt>3173 <t>If the transfer-coding being tested is one of the transfer-codings3174 listed in the TE field, then it is acceptable unless it3175 is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a3176 qvalue of 0 means "not acceptable".)</t>3177 </x:lt>3178 <x:lt>3179 <t>If multiple transfer-codings are acceptable, then the3180 acceptable transfer-coding with the highest non-zero qvalue is3181 preferred. The "chunked" transfer-coding always has a qvalue3182 of 1.</t>3183 </x:lt>3184 </list>3185 </t>3186 <t>3187 If the TE field-value is empty or if no TE field is present, the only3188 acceptable transfer-coding is "chunked". A message with no transfer-coding is3189 always acceptable.3190 </t>3191 </section>3192 3193 <section title="Trailer" anchor="header.trailer">3194 <iref primary="true" item="Trailer header field" x:for-anchor=""/>3195 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>3196 <x:anchor-alias value="Trailer"/>3197 <t>3198 The "Trailer" header field indicates that the given set of3199 header fields is present in the trailer of a message encoded with3200 chunked transfer-coding.3201 </t>3202 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>3203 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>3204 </artwork></figure>3205 <t>3206 An HTTP/1.1 message &SHOULD; include a Trailer header field in a3207 message using chunked transfer-coding with a non-empty trailer. Doing3208 so allows the recipient to know which header fields to expect in the3209 trailer.3210 </t>3211 <t>3212 If no Trailer header field is present, the trailer &SHOULD-NOT; include3213 any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of3214 trailer fields in a "chunked" transfer-coding.3215 </t>3216 <t>3217 Message header fields listed in the Trailer header field &MUST-NOT;3218 include the following header fields:3219 <list style="symbols">3220 <t>Transfer-Encoding</t>3221 <t>Content-Length</t>3222 <t>Trailer</t>3223 </list>3224 </t>3225 </section>3226 3227 <section title="Transfer-Encoding" anchor="header.transfer-encoding">3228 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>3229 <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/>3230 <x:anchor-alias value="Transfer-Encoding"/>3231 <t>3232 The "Transfer-Encoding" header field indicates what transfer-codings3233 (if any) have been applied to the message body. It differs from3234 Content-Encoding (&content-codings;) in that transfer-codings are a property3235 of the message (and therefore are removed by intermediaries), whereas3236 content-codings are not.3237 </t>3238 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>3239 <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref>3240 </artwork></figure>3241 <t>3242 Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:3243 </t>3244 <figure><artwork type="example">3245 Transfer-Encoding: chunked3246 </artwork></figure>3247 <t>3248 If multiple encodings have been applied to a representation, the transfer-codings3249 &MUST; be listed in the order in which they were applied.3250 Additional information about the encoding parameters &MAY; be provided3251 by other header fields not defined by this specification.3252 </t>3253 <t>3254 Many older HTTP/1.0 applications do not understand the Transfer-Encoding3255 header field.3256 </t>3257 </section>3258 3259 3228 <section title="Upgrade" anchor="header.upgrade"> 3260 3229 <iref primary="true" item="Upgrade header field" x:for-anchor=""/> 3261 3230 <iref primary="true" item="Header Fields" subitem="Upgrade" x:for-anchor=""/> 3262 3231 <x:anchor-alias value="Upgrade"/> 3232 <x:anchor-alias value="protocol"/> 3233 <x:anchor-alias value="protocol-name"/> 3234 <x:anchor-alias value="protocol-version"/> 3263 3235 <t> 3264 3236 The "Upgrade" header field allows the client to specify what … … 3268 3240 </t> 3269 3241 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> 3270 <x:ref>Upgrade</x:ref> = 1#<x:ref>product</x:ref> 3242 <x:ref>Upgrade</x:ref> = 1#<x:ref>protocol</x:ref> 3243 3244 <x:ref>protocol</x:ref> = <x:ref>protocol-name</x:ref> ["/" <x:ref>protocol-version</x:ref>] 3245 <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref> 3246 <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref> 3271 3247 </artwork></figure> 3272 3248 <t> … … 3328 3304 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> 3329 3305 <t> 3330 The HTTP Upgrade Token Registry defines the name space for pro duct3306 The HTTP Upgrade Token Registry defines the name space for protocol-name 3331 3307 tokens used to identify protocols in the Upgrade header field. 3332 Each registered tokenis associated with contact information and3308 Each registered protocol-name is associated with contact information and 3333 3309 an optional set of specifications that details how the connection 3334 3310 will be processed after it has been upgraded. … … 3340 3316 Registrations are subject to the following rules: 3341 3317 <list style="numbers"> 3342 <t>A token, once registered, stays registered forever.</t>3318 <t>A protocol-name token, once registered, stays registered forever.</t> 3343 3319 <t>The registration &MUST; name a responsible party for the 3344 3320 registration.</t> 3345 3321 <t>The registration &MUST; name a point of contact.</t> 3346 <t>The registration &MAY; name a set of specifications associated with that 3347 token. Such specifications need not be publicly available.</t> 3322 <t>The registration &MAY; name a set of specifications associated with 3323 that token. Such specifications need not be publicly available.</t> 3324 <t>The registration &SHOULD; name a set of expected "protocol-version" 3325 tokens associated with that token at the time of registration.</t> 3348 3326 <t>The responsible party &MAY; change the registration at any time. 3349 3327 The IANA will keep a record of all such changes, and make them 3350 3328 available upon request.</t> 3351 <t>The responsible party for the first registration of a "product" 3352 token &MUST; approve later registrations of a "version" token 3353 together with that "product" token before they can be registered.</t> 3354 <t>If absolutely required, the IESG &MAY; reassign the responsibility 3355 for a token. This will normally only be used in the case when a 3329 <t>The IESG &MAY; reassign responsibility for a protocol token. 3330 This will normally only be used in the case when a 3356 3331 responsible party cannot be contacted.</t> 3357 3332 </list> … … 3365 3340 <iref primary="true" item="Via header field" x:for-anchor=""/> 3366 3341 <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/> 3367 <x:anchor-alias value="protocol-name"/>3368 <x:anchor-alias value="protocol-version"/>3369 3342 <x:anchor-alias value="pseudonym"/> 3370 3343 <x:anchor-alias value="received-by"/> … … 3385 3358 [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] ) 3386 3359 <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref> 3387 <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref>3388 <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref>3389 3360 <x:ref>received-by</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref> 3390 3361 <x:ref>pseudonym</x:ref> = <x:ref>token</x:ref> … … 5082 5053 5083 5054 <x:ref>URI-reference</x:ref> = <URI-reference, defined in [RFC3986], Section 4.1> 5084 <x:ref>Upgrade</x:ref> = *( "," OWS ) pro duct *( OWS "," [ OWS product] )5055 <x:ref>Upgrade</x:ref> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 5085 5056 5086 5057 <x:ref>Via</x:ref> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] … … 5124 5095 <x:ref>path-absolute</x:ref> = <path-absolute, defined in [RFC3986], Section 3.3> 5125 5096 <x:ref>port</x:ref> = <port, defined in [RFC3986], Section 3.2.3> 5126 <x:ref>product</x:ref> = token [ "/" product-version ] 5127 <x:ref>product-version</x:ref> = token 5097 <x:ref>protocol</x:ref> = protocol-name [ "/" protocol-version ] 5128 5098 <x:ref>protocol-name</x:ref> = token 5129 5099 <x:ref>protocol-version</x:ref> = token -
draft-ietf-httpbis/latest/p2-semantics.html
r1536 r1538 460 460 } 461 461 @bottom-center { 462 content: "Expires August 19, 2012";462 content: "Expires August 21, 2012"; 463 463 } 464 464 @bottom-right { … … 490 490 <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7"> 491 491 <link rel="Chapter" title="8 Date/Time Formats" href="#rfc.section.8"> 492 <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9"> 493 <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10"> 494 <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11"> 495 <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12"> 496 <link rel="Chapter" href="#rfc.section.13" title="13 References"> 492 <link rel="Chapter" title="9 Product Tokens" href="#rfc.section.9"> 493 <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10"> 494 <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"> 495 <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12"> 496 <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13"> 497 <link rel="Chapter" href="#rfc.section.14" title="14 References"> 497 498 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 498 499 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> … … 512 513 <meta name="dct.creator" content="Reschke, J. F."> 513 514 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 514 <meta name="dct.issued" scheme="ISO8601" content="2012-02-1 6">515 <meta name="dct.issued" scheme="ISO8601" content="2012-02-18"> 515 516 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 516 517 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 543 544 </tr> 544 545 <tr> 545 <td class="left">Expires: August 19, 2012</td>546 <td class="left">Expires: August 21, 2012</td> 546 547 <td class="right">HP</td> 547 548 </tr> … … 596 597 <tr> 597 598 <td class="left"></td> 598 <td class="right">February 1 6, 2012</td>599 <td class="right">February 18, 2012</td> 599 600 </tr> 600 601 </tbody> … … 626 627 in progress”. 627 628 </p> 628 <p>This Internet-Draft will expire on August 19, 2012.</p>629 <p>This Internet-Draft will expire on August 21, 2012.</p> 629 630 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 630 631 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 753 754 </li> 754 755 <li>8. <a href="#http.date">Date/Time Formats</a></li> 755 <li>9. <a href="#header.field.definitions">Header Field Definitions</a><ul> 756 <li>9.1 <a href="#header.allow">Allow</a></li> 757 <li>9.2 <a href="#header.date">Date</a></li> 758 <li>9.3 <a href="#header.expect">Expect</a></li> 759 <li>9.4 <a href="#header.from">From</a></li> 760 <li>9.5 <a href="#header.location">Location</a></li> 761 <li>9.6 <a href="#header.max-forwards">Max-Forwards</a></li> 762 <li>9.7 <a href="#header.referer">Referer</a></li> 763 <li>9.8 <a href="#header.retry-after">Retry-After</a></li> 764 <li>9.9 <a href="#header.server">Server</a></li> 765 <li>9.10 <a href="#header.user-agent">User-Agent</a></li> 756 <li>9. <a href="#product.tokens">Product Tokens</a></li> 757 <li>10. <a href="#header.field.definitions">Header Field Definitions</a><ul> 758 <li>10.1 <a href="#header.allow">Allow</a></li> 759 <li>10.2 <a href="#header.date">Date</a></li> 760 <li>10.3 <a href="#header.expect">Expect</a></li> 761 <li>10.4 <a href="#header.from">From</a></li> 762 <li>10.5 <a href="#header.location">Location</a></li> 763 <li>10.6 <a href="#header.max-forwards">Max-Forwards</a></li> 764 <li>10.7 <a href="#header.referer">Referer</a></li> 765 <li>10.8 <a href="#header.retry-after">Retry-After</a></li> 766 <li>10.9 <a href="#header.server">Server</a></li> 767 <li>10.10 <a href="#header.user-agent">User-Agent</a></li> 766 768 </ul> 767 769 </li> 768 <li>1 0. <a href="#IANA.considerations">IANA Considerations</a><ul>769 <li>1 0.1 <a href="#method.registration">Method Registry</a></li>770 <li>1 0.2 <a href="#status.code.registration">Status Code Registry</a></li>771 <li>1 0.3 <a href="#header.field.registration">Header Field Registration</a></li>770 <li>11. <a href="#IANA.considerations">IANA Considerations</a><ul> 771 <li>11.1 <a href="#method.registration">Method Registry</a></li> 772 <li>11.2 <a href="#status.code.registration">Status Code Registry</a></li> 773 <li>11.3 <a href="#header.field.registration">Header Field Registration</a></li> 772 774 </ul> 773 775 </li> 774 <li>1 1. <a href="#security.considerations">Security Considerations</a><ul>775 <li>1 1.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>776 <li>1 1.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>777 <li>1 1.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>778 <li>1 1.4 <a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li>776 <li>12. <a href="#security.considerations">Security Considerations</a><ul> 777 <li>12.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 778 <li>12.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 779 <li>12.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 780 <li>12.4 <a href="#rfc.section.12.4">Security Considerations for CONNECT</a></li> 779 781 </ul> 780 782 </li> 781 <li>1 2. <a href="#acks">Acknowledgments</a></li>782 <li>1 3. <a href="#rfc.references">References</a><ul>783 <li>1 3.1 <a href="#rfc.references.1">Normative References</a></li>784 <li>1 3.2 <a href="#rfc.references.2">Informative References</a></li>783 <li>13. <a href="#acks">Acknowledgments</a></li> 784 <li>14. <a href="#rfc.references">References</a><ul> 785 <li>14.1 <a href="#rfc.references.1">Normative References</a></li> 786 <li>14.2 <a href="#rfc.references.2">Informative References</a></li> 785 787 </ul> 786 788 </li> … … 864 866 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 865 867 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><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.7</a>> 866 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>> 867 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 868 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><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.7</a>> 868 869 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 869 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.870 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<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>). The method is case-sensitive. 870 871 </p> 871 872 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">Method</a> = <a href="#core.rules" class="smpl">token</a> 872 </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 the873 </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 10.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 873 874 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 874 875 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET … … 946 947 to a single application, so that this is clear. 947 948 </p> 948 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message949 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message 949 950 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 950 951 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 955 956 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 956 957 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 957 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.958 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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> for a general definition of their syntax. 958 959 </p> 959 960 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> … … 963 964 with "X-" if they are to be registered (either immediately or in the future). 964 965 </p> 965 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters966 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 966 967 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 967 968 </p> 968 969 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 969 970 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 970 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</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>).971 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.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>). 971 972 </p> 972 973 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 986 987 <ul> 987 988 <li> 988 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).989 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>). 989 990 </p> 990 991 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 1002 1003 </li> 1003 1004 <li> 1004 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</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>).1005 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 9.1</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>). 1005 1006 </p> 1006 1007 </li> … … 1013 1014 </li> 1014 1015 <li> 1015 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1 .1</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1016 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</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>). 1016 1017 </p> 1017 1018 </li> … … 1056 1057 <tr> 1057 1058 <td class="left">Expect</td> 1058 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.3</a></td>1059 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.3</a></td> 1059 1060 </tr> 1060 1061 <tr> 1061 1062 <td class="left">From</td> 1062 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.4</a></td>1063 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.4</a></td> 1063 1064 </tr> 1064 1065 <tr> 1065 1066 <td class="left">Host</td> 1066 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1067 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1067 1068 </tr> 1068 1069 <tr> … … 1088 1089 <tr> 1089 1090 <td class="left">Max-Forwards</td> 1090 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.6</a></td>1091 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.6</a></td> 1091 1092 </tr> 1092 1093 <tr> … … 1100 1101 <tr> 1101 1102 <td class="left">Referer</td> 1102 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.7</a></td>1103 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.7</a></td> 1103 1104 </tr> 1104 1105 <tr> 1105 1106 <td class="left">TE</td> 1106 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1107 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1107 1108 </tr> 1108 1109 <tr> 1109 1110 <td class="left">User-Agent</td> 1110 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.10</a></td>1111 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.10</a></td> 1111 1112 </tr> 1112 1113 </tbody> … … 1115 1116 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1116 1117 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1117 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1118 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1118 1119 </p> 1119 1120 <div id="rfc.table.u.3"> … … 1136 1137 <tr> 1137 1138 <td class="left">Allow</td> 1138 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 9.1</a></td>1139 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 10.1</a></td> 1139 1140 </tr> 1140 1141 <tr> 1141 1142 <td class="left">Date</td> 1142 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 9.2</a></td>1143 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 10.2</a></td> 1143 1144 </tr> 1144 1145 <tr> … … 1148 1149 <tr> 1149 1150 <td class="left">Location</td> 1150 <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.5</a></td>1151 <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.5</a></td> 1151 1152 </tr> 1152 1153 <tr> … … 1156 1157 <tr> 1157 1158 <td class="left">Retry-After</td> 1158 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.8</a></td>1159 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.8</a></td> 1159 1160 </tr> 1160 1161 <tr> 1161 1162 <td class="left">Server</td> 1162 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.9</a></td>1163 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.9</a></td> 1163 1164 </tr> 1164 1165 <tr> … … 1437 1438 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1438 1439 </p> 1439 <p id="rfc.section.5.p.2">A representation 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.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1440 <p id="rfc.section.5.p.2">A representation 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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 1440 1441 to ensure safe and proper transfer of the message. 1441 1442 </p> … … 1443 1444 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1444 1445 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 1445 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (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.2 8"><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 following1446 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (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.27"><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 1446 1447 rules are used (with the first applicable one being selected): 1447 1448 </p> … … 1513 1514 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 1514 1515 </p> 1515 <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.1516 <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1516 1517 </p> 1517 1518 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2> … … 1537 1538 <p id="rfc.section.6.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1538 1539 </p> 1539 <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 1 1.2</a> for security considerations when used for forms.1540 <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms. 1540 1541 </p> 1541 1542 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> … … 1573 1574 </p> 1574 1575 <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1575 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.5</a>).1576 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.5</a>). 1576 1577 </p> 1577 1578 <p id="rfc.section.6.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 field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</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>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. … … 1663 1664 <div id="rfc.iref.m.7"></div> 1664 1665 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either 1665 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.1666 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body. 1666 1667 </p> 1667 1668 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1668 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1669 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1669 1670 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1670 1671 infinite loop. 1671 1672 </p> 1672 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1673 1674 </p> 1674 1675 <div id="rfc.iref.c.1"></div> … … 1678 1679 forwarding of packets until the connection is closed. 1679 1680 </p> 1680 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1681 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1681 1682 For example, 1682 1683 </p> … … 1745 1746 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1746 1747 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1747 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1748 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1748 1749 </p> 1749 1750 <div id="rfc.iref.23"></div> 1750 1751 <div id="rfc.iref.s.3"></div> 1751 1752 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1752 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1753 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1753 1754 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1754 1755 </p> … … 1803 1804 <div id="rfc.iref.s.7"></div> 1804 1805 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1805 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1806 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1806 1807 </p> 1807 1808 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1838 1839 another input action. 1839 1840 </p> 1840 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1841 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1841 1842 </p> 1842 1843 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1876 1877 </p> 1877 1878 </div> 1878 <p id="rfc.section.7.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9.5</a>.1879 <p id="rfc.section.7.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.5</a>. 1879 1880 </p> 1880 1881 <p id="rfc.section.7.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was … … 2092 2093 <div id="rfc.iref.s.30"></div> 2093 2094 <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2094 <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could2095 <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 2095 2096 not be met by the next-hop server. 2096 2097 </p> … … 2098 2099 <div id="rfc.iref.s.31"></div> 2099 2100 <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2100 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2101 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2101 2102 </p> 2102 2103 <div id="rfc.figure.u.8"></div> … … 2137 2138 <p id="rfc.section.7.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 2138 2139 <p id="rfc.section.7.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the 2139 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 9.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.2140 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 10.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2140 2141 </p> 2141 2142 <div class="note" id="rfc.section.7.5.4.p.3"> … … 2159 2160 <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2160 2161 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2161 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2162 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2162 2163 </p> 2163 2164 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> … … 2247 2248 </p> 2248 2249 </div> 2249 <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> 2250 <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> 2250 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1> 2251 <p id="rfc.section.9.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 2252 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. 2253 By convention, the products are listed in order of their significance for identifying the application. 2254 </p> 2255 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#core.rules" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 2256 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a> 2257 </pre><p id="rfc.section.9.p.3">Examples:</p> 2258 <div id="rfc.figure.u.17"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2259 Server: Apache/0.8.4 2260 </pre><p id="rfc.section.9.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 2261 </p> 2262 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 2263 <p id="rfc.section.10.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 2251 2264 <div id="rfc.iref.a.1"></div> 2252 2265 <div id="rfc.iref.h.2"></div> 2253 <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>2254 <p id="rfc.section. 9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field2266 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2267 <p id="rfc.section.10.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2255 2268 is strictly to inform the recipient of valid request methods associated with the resource. 2256 2269 </p> 2257 <div id="rfc.figure.u.1 6"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a>2258 </pre><p id="rfc.section. 9.1.p.3">Example of use:</p>2259 <div id="rfc.figure.u.1 7"></div><pre class="text"> Allow: GET, HEAD, PUT2260 </pre><p id="rfc.section. 9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>2261 <p id="rfc.section. 9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according2270 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a> 2271 </pre><p id="rfc.section.10.1.p.3">Example of use:</p> 2272 <div id="rfc.figure.u.19"></div><pre class="text"> Allow: GET, HEAD, PUT 2273 </pre><p id="rfc.section.10.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 2274 <p id="rfc.section.10.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according 2262 2275 to the generic message handling rules. 2263 2276 </p> 2264 2277 <div id="rfc.iref.d.2"></div> 2265 2278 <div id="rfc.iref.h.3"></div> 2266 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.date" href="#header.date">Date</a></h2>2267 <p id="rfc.section. 9.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2279 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="header.date" href="#header.date">Date</a></h2> 2280 <p id="rfc.section.10.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2268 2281 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 8</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2269 2282 </p> 2270 <div id="rfc.figure.u. 18"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>2271 </pre><p id="rfc.section. 9.2.p.3">An example is</p>2272 <div id="rfc.figure.u. 19"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2273 </pre><p id="rfc.section. 9.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:2283 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> 2284 </pre><p id="rfc.section.10.2.p.3">An example is</p> 2285 <div id="rfc.figure.u.21"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2286 </pre><p id="rfc.section.10.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2274 2287 </p> 2275 2288 <ol> … … 2282 2295 </li> 2283 2296 </ol> 2284 <p id="rfc.section. 9.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.2285 </p> 2286 <p id="rfc.section. 9.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it2297 <p id="rfc.section.10.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. 2298 </p> 2299 <p id="rfc.section.10.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it 2287 2300 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2288 2301 </p> 2289 <p id="rfc.section. 9.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means2302 <p id="rfc.section.10.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means 2290 2303 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2291 2304 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2294 2307 <div id="rfc.iref.e.1"></div> 2295 2308 <div id="rfc.iref.h.4"></div> 2296 <h2 id="rfc.section. 9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2>2297 <p id="rfc.section. 9.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>2298 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>2309 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 2310 <p id="rfc.section.10.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 2311 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 2299 2312 2300 2313 <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] … … 2304 2317 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2305 2318 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2306 </pre><p id="rfc.section. 9.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand2319 </pre><p id="rfc.section.10.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2307 2320 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2308 2321 </p> 2309 <p id="rfc.section. 9.3.p.4">The only expectation defined by this specification is:</p>2310 <p id="rfc.section. 9.3.p.5"><span id="rfc.iref.87"></span><span id="rfc.iref.e.2"></span> 100-continue2322 <p id="rfc.section.10.3.p.4">The only expectation defined by this specification is:</p> 2323 <p id="rfc.section.10.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue 2311 2324 </p> 2312 2325 <ul class="empty"> 2313 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2326 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2314 2327 </li> 2315 2328 </ul> 2316 <p id="rfc.section. 9.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>2317 <p id="rfc.section. 9.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header2329 <p id="rfc.section.10.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 2330 <p id="rfc.section.10.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 2318 2331 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2319 2332 </p> 2320 <p id="rfc.section. 9.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>2333 <p id="rfc.section.10.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2321 2334 <div id="rfc.iref.f.1"></div> 2322 2335 <div id="rfc.iref.h.5"></div> 2323 <h2 id="rfc.section. 9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.from" href="#header.from">From</a></h2>2324 <p id="rfc.section. 9.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:2325 </p> 2326 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>2336 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="header.from" href="#header.from">From</a></h2> 2337 <p id="rfc.section.10.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2338 </p> 2339 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2327 2340 2328 2341 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> 2329 </pre><p id="rfc.section. 9.4.p.3">An example is:</p>2330 <div id="rfc.figure.u.2 2"></div><pre class="text"> From: webmaster@example.org2331 </pre><p id="rfc.section. 9.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed2342 </pre><p id="rfc.section.10.4.p.3">An example is:</p> 2343 <div id="rfc.figure.u.24"></div><pre class="text"> From: webmaster@example.org 2344 </pre><p id="rfc.section.10.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 2332 2345 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving 2333 2346 end. 2334 2347 </p> 2335 <p id="rfc.section. 9.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original2348 <p id="rfc.section.10.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 2336 2349 issuer's address <em class="bcp14">SHOULD</em> be used. 2337 2350 </p> 2338 <p id="rfc.section. 9.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's2351 <p id="rfc.section.10.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 2339 2352 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2340 2353 any time prior to a request. … … 2342 2355 <div id="rfc.iref.l.1"></div> 2343 2356 <div id="rfc.iref.h.6"></div> 2344 <h2 id="rfc.section. 9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.location" href="#header.location">Location</a></h2>2345 <p id="rfc.section. 9.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.2346 </p> 2347 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>2348 </pre><p id="rfc.section. 9.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,2357 <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="header.location" href="#header.location">Location</a></h2> 2358 <p id="rfc.section.10.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 2359 </p> 2360 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2361 </pre><p id="rfc.section.10.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2349 2362 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2350 2363 </p> 2351 <p id="rfc.section. 9.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,2364 <p id="rfc.section.10.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, 2352 2365 then the original URI's fragment identifier is added to the final value. 2353 2366 </p> 2354 <div id="rfc.figure.u.2 4"></div>2367 <div id="rfc.figure.u.26"></div> 2355 2368 <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim 2356 2369 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2357 <div id="rfc.figure.u.2 5"></div>2370 <div id="rfc.figure.u.27"></div> 2358 2371 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2359 2372 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2360 <div class="note" id="rfc.section. 9.5.p.7">2373 <div class="note" id="rfc.section.10.5.p.7"> 2361 2374 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2362 2375 or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.1</a>). 2363 2376 </p> 2364 2377 </div> 2365 <p id="rfc.section. 9.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears2378 <p id="rfc.section.10.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2366 2379 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2367 2380 </p> 2368 <div class="note" id="rfc.section. 9.5.p.9">2381 <div class="note" id="rfc.section.10.5.p.9"> 2369 2382 <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.13"><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. 2370 2383 It is therefore possible for a response to contain header fields for both Location and Content-Location. … … 2373 2386 <div id="rfc.iref.m.9"></div> 2374 2387 <div id="rfc.iref.h.7"></div> 2375 <h2 id="rfc.section. 9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>2376 <p id="rfc.section. 9.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting2388 <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2389 <p id="rfc.section.10.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2377 2390 to trace a request which appears to be failing or looping mid-chain. 2378 2391 </p> 2379 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2380 </pre><p id="rfc.section. 9.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>2381 <p id="rfc.section. 9.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).2382 </p> 2383 <p id="rfc.section. 9.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.2392 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2393 </pre><p id="rfc.section.10.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2394 <p id="rfc.section.10.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 2395 </p> 2396 <p id="rfc.section.10.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 2384 2397 </p> 2385 2398 <div id="rfc.iref.r.1"></div> 2386 2399 <div id="rfc.iref.h.8"></div> 2387 <h2 id="rfc.section. 9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2>2388 <p id="rfc.section. 9.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI2400 <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 2401 <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI 2389 2402 was obtained (the "referrer", although the header field is misspelled.). 2390 2403 </p> 2391 <p id="rfc.section. 9.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,2404 <p id="rfc.section.10.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 2392 2405 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2393 2406 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2394 2407 </p> 2395 <p id="rfc.section. 9.7.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),2408 <p id="rfc.section.10.7.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), 2396 2409 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 2397 2410 non-HTTP URIs (e.g., FTP). 2398 2411 </p> 2399 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>2400 </pre><p id="rfc.section. 9.7.p.5">Example:</p>2401 <div id="rfc.figure.u. 28"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html2402 </pre><p id="rfc.section. 9.7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations.2412 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2413 </pre><p id="rfc.section.10.7.p.5">Example:</p> 2414 <div id="rfc.figure.u.30"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2415 </pre><p id="rfc.section.10.7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations. 2403 2416 </p> 2404 2417 <div id="rfc.iref.r.2"></div> 2405 2418 <div id="rfc.iref.h.9"></div> 2406 <h2 id="rfc.section. 9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>2407 <p id="rfc.section. 9.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected2419 <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 2420 <p id="rfc.section.10.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2408 2421 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing 2409 2422 the redirected request. 2410 2423 </p> 2411 <p id="rfc.section. 9.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>2412 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>2424 <p id="rfc.section.10.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 2425 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2413 2426 </pre><div id="rule.delta-seconds"> 2414 <p id="rfc.section. 9.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>2427 <p id="rfc.section.10.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2415 2428 </div> 2416 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2417 </pre><p id="rfc.section. 9.8.p.6">Two examples of its use are</p>2418 <div id="rfc.figure.u.3 1"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT2429 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2430 </pre><p id="rfc.section.10.8.p.6">Two examples of its use are</p> 2431 <div id="rfc.figure.u.33"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2419 2432 Retry-After: 120 2420 </pre><p id="rfc.section. 9.8.p.8">In the latter example, the delay is 2 minutes.</p>2433 </pre><p id="rfc.section.10.8.p.8">In the latter example, the delay is 2 minutes.</p> 2421 2434 <div id="rfc.iref.s.38"></div> 2422 2435 <div id="rfc.iref.h.10"></div> 2423 <h2 id="rfc.section. 9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.server" href="#header.server">Server</a></h2>2424 <p id="rfc.section. 9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>2425 <p id="rfc.section. 9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2436 <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2437 <p id="rfc.section.10.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2438 <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2426 2439 identifying the application. 2427 2440 </p> 2428 <div id="rfc.figure.u.3 2"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2429 </pre><p id="rfc.section. 9.9.p.4">Example:</p>2430 <div id="rfc.figure.u.3 3"></div><pre class="text"> Server: CERN/3.0 libwww/2.172431 </pre><p id="rfc.section. 9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2432 </p> 2433 <div class="note" id="rfc.section. 9.9.p.7">2441 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.37"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2442 </pre><p id="rfc.section.10.9.p.4">Example:</p> 2443 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2444 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2445 </p> 2446 <div class="note" id="rfc.section.10.9.p.7"> 2434 2447 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2435 2448 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable … … 2439 2452 <div id="rfc.iref.u.1"></div> 2440 2453 <div id="rfc.iref.h.11"></div> 2441 <h2 id="rfc.section. 9.10"><a href="#rfc.section.9.10">9.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>2442 <p id="rfc.section. 9.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.2443 </p> 2444 <p id="rfc.section. 9.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular2454 <h2 id="rfc.section.10.10"><a href="#rfc.section.10.10">10.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 2455 <p id="rfc.section.10.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests. 2456 </p> 2457 <p id="rfc.section.10.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular 2445 2458 user agent limitations. 2446 2459 </p> 2447 <p id="rfc.section. 9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2460 <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2448 2461 for identifying the application. 2449 2462 </p> 2450 <p id="rfc.section. 9.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly2463 <p id="rfc.section.10.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly 2451 2464 fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed 2452 2465 User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. 2453 2466 </p> 2454 <p id="rfc.section. 9.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility2467 <p id="rfc.section.10.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility 2455 2468 with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; 2456 2469 doing so makes the field value more difficult to parse. 2457 2470 </p> 2458 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2459 </pre><p id="rfc.section. 9.10.p.7">Example:</p>2460 <div id="rfc.figure.u.3 5"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b32461 </pre><h1 id="rfc.section.1 0"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>2462 <h2 id="rfc.section.1 0.1"><a href="#rfc.section.10.1">10.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2>2463 <p id="rfc.section.1 0.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document.2464 </p> 2465 <p id="rfc.section.1 0.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below:2471 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.38"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2472 </pre><p id="rfc.section.10.10.p.7">Example:</p> 2473 <div id="rfc.figure.u.37"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2474 </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2475 <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> 2476 <p id="rfc.section.11.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document. 2477 </p> 2478 <p id="rfc.section.11.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 2466 2479 </p> 2467 2480 <div id="rfc.table.1"> … … 2527 2540 </table> 2528 2541 </div> 2529 <h2 id="rfc.section.1 0.2"><a href="#rfc.section.10.2">10.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>2530 <p id="rfc.section.1 0.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.2</a> of this document.2531 </p> 2532 <p id="rfc.section.1 0.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below:2542 <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2> 2543 <p id="rfc.section.11.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.2</a> of this document. 2544 </p> 2545 <p id="rfc.section.11.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 2533 2546 </p> 2534 2547 <div id="rfc.table.2"> … … 2762 2775 </table> 2763 2776 </div> 2764 <h2 id="rfc.section.1 0.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>2765 <p id="rfc.section.1 0.3.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>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):2777 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2778 <p id="rfc.section.11.3.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>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2766 2779 </p> 2767 2780 <div id="rfc.table.3"> … … 2781 2794 <td class="left">http</td> 2782 2795 <td class="left">standard</td> 2783 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 9.1</a>2796 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 10.1</a> 2784 2797 </td> 2785 2798 </tr> … … 2788 2801 <td class="left">http</td> 2789 2802 <td class="left">standard</td> 2790 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.2</a>2803 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 10.2</a> 2791 2804 </td> 2792 2805 </tr> … … 2795 2808 <td class="left">http</td> 2796 2809 <td class="left">standard</td> 2797 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 9.3</a>2810 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 10.3</a> 2798 2811 </td> 2799 2812 </tr> … … 2802 2815 <td class="left">http</td> 2803 2816 <td class="left">standard</td> 2804 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 9.4</a>2817 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 10.4</a> 2805 2818 </td> 2806 2819 </tr> … … 2809 2822 <td class="left">http</td> 2810 2823 <td class="left">standard</td> 2811 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.5</a>2824 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 10.5</a> 2812 2825 </td> 2813 2826 </tr> … … 2816 2829 <td class="left">http</td> 2817 2830 <td class="left">standard</td> 2818 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 9.6</a>2831 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 10.6</a> 2819 2832 </td> 2820 2833 </tr> … … 2823 2836 <td class="left">http</td> 2824 2837 <td class="left">standard</td> 2825 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 9.7</a>2838 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 10.7</a> 2826 2839 </td> 2827 2840 </tr> … … 2830 2843 <td class="left">http</td> 2831 2844 <td class="left">standard</td> 2832 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 9.8</a>2845 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 10.8</a> 2833 2846 </td> 2834 2847 </tr> … … 2837 2850 <td class="left">http</td> 2838 2851 <td class="left">standard</td> 2839 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 9.9</a>2852 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.9</a> 2840 2853 </td> 2841 2854 </tr> … … 2844 2857 <td class="left">http</td> 2845 2858 <td class="left">standard</td> 2846 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.10</a>2859 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.10</a> 2847 2860 </td> 2848 2861 </tr> … … 2850 2863 </table> 2851 2864 </div> 2852 <p id="rfc.section.1 0.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>2853 <h1 id="rfc.section.1 1"><a href="#rfc.section.11">11.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>2854 <p id="rfc.section.1 1.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.12865 <p id="rfc.section.11.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2866 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2867 <p id="rfc.section.12.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 2855 2868 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 2856 2869 make some suggestions for reducing security risks. 2857 2870 </p> 2858 <h2 id="rfc.section.1 1.1"><a href="#rfc.section.11.1">11.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>2859 <p id="rfc.section.1 1.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any2871 <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> 2872 <p id="rfc.section.12.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any 2860 2873 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 2861 2874 Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth 2862 2875 special mention in this context: Server, Via, Referer and From. 2863 2876 </p> 2864 <p id="rfc.section.1 1.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks2877 <p id="rfc.section.12.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2865 2878 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. 2866 2879 </p> 2867 <p id="rfc.section.1 1.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,2880 <p id="rfc.section.12.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, 2868 2881 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 2869 2882 </p> 2870 <p id="rfc.section.1 1.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its2883 <p id="rfc.section.12.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its 2871 2884 power can be abused if user details are not separated from the information contained in the Referer. Even when the personal 2872 2885 information has been removed, the Referer header field might indicate a private document's URI whose publication would be 2873 2886 inappropriate. 2874 2887 </p> 2875 <p id="rfc.section.1 1.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and2888 <p id="rfc.section.12.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and 2876 2889 hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 2877 2890 </p> 2878 <p id="rfc.section.1 1.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending2891 <p id="rfc.section.12.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending 2879 2892 of From and Referer information. 2880 2893 </p> 2881 <p id="rfc.section.1 1.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might2894 <p id="rfc.section.12.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 10.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 2882 2895 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 2883 2896 no better mechanism. 2884 2897 </p> 2885 <p id="rfc.section.1 1.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,2898 <p id="rfc.section.12.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material, 2886 2899 to uniquely identify the user. 2887 2900 </p> 2888 <p id="rfc.section.1 1.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used2901 <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 2889 2902 to collect data from the client. 2890 2903 </p> 2891 <h2 id="rfc.section.1 1.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>2892 <p id="rfc.section.1 1.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly2904 <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> 2905 <p id="rfc.section.12.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly 2893 2906 recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could 2894 2907 have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From 2895 2908 information. 2896 2909 </p> 2897 <p id="rfc.section.1 1.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.2898 </p> 2899 <p id="rfc.section.1 1.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing2910 <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 2911 </p> 2912 <p id="rfc.section.12.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing 2900 2913 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 2901 2914 Such services can use POST-based form submission instead. 2902 2915 </p> 2903 <h2 id="rfc.section.1 1.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>2904 <p id="rfc.section.1 1.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations2916 <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> 2917 <p id="rfc.section.12.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations 2905 2918 to make sure that they do not attempt to invalidate resources over which they have no authority. 2906 2919 </p> 2907 <p id="rfc.section.1 1.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak2920 <p id="rfc.section.12.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak 2908 2921 confidential information to the target server — although the fragment identifier is not transmitted in the final request, 2909 2922 it might be visible to the user agent through other means, such as scripting. 2910 2923 </p> 2911 <h2 id="rfc.section.1 1.4"><a href="#rfc.section.11.4">11.4</a> Security Considerations for CONNECT2924 <h2 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a> Security Considerations for CONNECT 2912 2925 </h2> 2913 <p id="rfc.section.1 1.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.2926 <p id="rfc.section.12.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. 2914 2927 A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports. 2915 2928 </p> 2916 <h1 id="rfc.section.1 2"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>2917 <p id="rfc.section.1 2.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2918 </p> 2919 <h1 id="rfc.references"><a id="rfc.section.1 3" href="#rfc.section.13">13.</a> References2929 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2930 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2931 </p> 2932 <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References 2920 2933 </h1> 2921 <h2 id="rfc.references.1"><a href="#rfc.section.1 3.1" id="rfc.section.13.1">13.1</a> Normative References2934 <h2 id="rfc.references.1"><a href="#rfc.section.14.1" id="rfc.section.14.1">14.1</a> Normative References 2922 2935 </h2> 2923 2936 <table> … … 2968 2981 </tr> 2969 2982 </table> 2970 <h2 id="rfc.references.2"><a href="#rfc.section.1 3.2" id="rfc.section.13.2">13.2</a> Informative References2983 <h2 id="rfc.references.2"><a href="#rfc.section.14.2" id="rfc.section.14.2">14.2</a> Informative References 2971 2984 </h2> 2972 2985 <table> … … 3063 3076 <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.4.15</a>) 3064 3077 </p> 3065 <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3078 <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 10</a>) 3066 3079 </p> 3067 3080 <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3068 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>)3081 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 10.1</a>) 3069 3082 </p> 3070 3083 <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3071 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.3</a>)3084 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 10.3</a>) 3072 3085 </p> 3073 3086 <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3074 3087 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3075 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.5</a>)3076 </p> 3077 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.6</a>)3078 </p> 3079 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.7</a>)3088 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 10.5</a>) 3089 </p> 3090 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 10.6</a>) 3091 </p> 3092 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 10.7</a>) 3080 3093 </p> 3081 3094 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3082 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>)3095 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>) 3083 3096 </p> 3084 3097 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3085 <div id="rfc.figure.u.3 6"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]3098 <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 3086 3099 3087 3100 <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 3.2.1> … … 3167 3180 3168 3181 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.7> 3169 <a href="# abnf.dependencies" class="smpl">product</a> = <product, defined in [Part1], Section 5.2>3182 <a href="#product.tokens" class="smpl">product</a> = <product, defined in [Part1], Section 5.2> 3170 3183 3171 3184 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2.4> … … 3180 3193 3181 3194 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3182 </pre> <div id="rfc.figure.u.3 7"></div>3195 </pre> <div id="rfc.figure.u.39"></div> 3183 3196 <p>ABNF diagnostics:</p><pre class="inline">; Allow defined but not used 3184 3197 ; Date defined but not used … … 3510 3523 <ul class="ind"> 3511 3524 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 3512 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">1 0.2</a></li>3513 <li>100-continue (expect value) <a href="#rfc.iref.8 7"><b>9.3</b></a></li>3514 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">1 0.2</a></li>3525 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> 3526 <li>100-continue (expect value) <a href="#rfc.iref.89"><b>10.3</b></a></li> 3527 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> 3515 3528 </ul> 3516 3529 </li> 3517 3530 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 3518 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">1 0.2</a></li>3519 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">1 0.2</a></li>3520 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">1 0.2</a></li>3521 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">1 0.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3522 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">1 0.2</a></li>3523 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">1 0.2</a></li>3531 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> 3532 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li> 3533 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> 3534 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> 3535 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> 3536 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> 3524 3537 </ul> 3525 3538 </li> 3526 3539 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 3527 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">1 0.2</a></li>3528 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">1 0.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3529 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">1 0.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3530 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">1 0.2</a></li>3531 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">1 0.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3532 <li>306 (Unused) (status code) <a href="#rfc.iref.35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">1 0.2</a></li>3533 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">1 0.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>3540 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> 3541 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A</a></li> 3542 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A</a></li> 3543 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> 3544 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A</a></li> 3545 <li>306 (Unused) (status code) <a href="#rfc.iref.35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> 3546 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A</a></li> 3534 3547 </ul> 3535 3548 </li> 3536 3549 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 3537 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">1 0.2</a></li>3538 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">1 0.2</a></li>3539 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">1 0.2</a></li>3540 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">1 0.2</a></li>3541 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">1 0.2</a></li>3542 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">1 0.2</a></li>3543 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">1 0.2</a></li>3544 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">1 0.2</a></li>3545 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">1 0.2</a></li>3546 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">1 0.2</a></li>3547 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">1 0.2</a></li>3548 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">1 0.2</a></li>3549 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">1 0.2</a></li>3550 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">1 0.2</a></li>3551 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">1 0.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>3550 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> 3551 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> 3552 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li> 3553 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li> 3554 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> 3555 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> 3556 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> 3557 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> 3558 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li> 3559 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> 3560 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> 3561 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> 3562 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> 3563 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> 3564 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">A</a></li> 3552 3565 </ul> 3553 3566 </li> 3554 3567 <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> 3555 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">1 0.2</a></li>3556 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">1 0.2</a></li>3557 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">1 0.2</a></li>3558 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">1 0.2</a></li>3559 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">1 0.2</a></li>3560 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">1 0.2</a></li>3568 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> 3569 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> 3570 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> 3571 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> 3572 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li> 3573 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> 3561 3574 </ul> 3562 3575 </li> 3563 3576 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3564 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b> 9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>3577 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3565 3578 </ul> 3566 3579 </li> 3567 3580 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3568 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">1 0.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>3581 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li> 3569 3582 </ul> 3570 3583 </li> 3571 3584 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3572 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b> 9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>3573 <li>DELETE method <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">1 0.1</a></li>3585 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li> 3586 <li>DELETE method <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> 3574 3587 </ul> 3575 3588 </li> 3576 3589 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3577 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.e.1"><b> 9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>3590 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.e.1"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3578 3591 <li>Expect Values 3579 3592 <ul> 3580 <li>100-continue <a href="#rfc.iref.e.2"><b> 9.3</b></a></li>3593 <li>100-continue <a href="#rfc.iref.e.2"><b>10.3</b></a></li> 3581 3594 </ul> 3582 3595 </li> … … 3584 3597 </li> 3585 3598 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 3586 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b> 9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>3599 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> 3587 3600 </ul> 3588 3601 </li> 3589 3602 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3590 <li>GET method <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">1 0.1</a></li>3603 <li>GET method <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> 3591 3604 <li><tt>Grammar</tt> 3592 3605 <ul> 3593 <li><tt>Allow</tt> <a href="#rfc.iref.g.2 2"><b>9.1</b></a></li>3606 <li><tt>Allow</tt> <a href="#rfc.iref.g.24"><b>10.1</b></a></li> 3594 3607 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b>8</b></a></li> 3595 <li><tt>Date</tt> <a href="#rfc.iref.g.2 3"><b>9.2</b></a></li>3608 <li><tt>Date</tt> <a href="#rfc.iref.g.25"><b>10.2</b></a></li> 3596 3609 <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b>8</b></a></li> 3597 3610 <li><tt>day</tt> <a href="#rfc.iref.g.15"><b>8</b></a></li> 3598 3611 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b>8</b></a></li> 3599 3612 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b>8</b></a></li> 3600 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.3 4"><b>9.8</b></a></li>3601 <li><tt>Expect</tt> <a href="#rfc.iref.g.2 4"><b>9.3</b></a></li>3602 <li><tt>expect-name</tt> <a href="#rfc.iref.g. 28"><b>9.3</b></a></li>3603 <li><tt>expect-param</tt> <a href="#rfc.iref.g.2 6"><b>9.3</b></a></li>3604 <li><tt>expect-value</tt> <a href="#rfc.iref.g.2 7"><b>9.3</b></a></li>3605 <li><tt>expectation</tt> <a href="#rfc.iref.g.2 5"><b>9.3</b></a></li>3613 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.36"><b>10.8</b></a></li> 3614 <li><tt>Expect</tt> <a href="#rfc.iref.g.26"><b>10.3</b></a></li> 3615 <li><tt>expect-name</tt> <a href="#rfc.iref.g.30"><b>10.3</b></a></li> 3616 <li><tt>expect-param</tt> <a href="#rfc.iref.g.28"><b>10.3</b></a></li> 3617 <li><tt>expect-value</tt> <a href="#rfc.iref.g.29"><b>10.3</b></a></li> 3618 <li><tt>expectation</tt> <a href="#rfc.iref.g.27"><b>10.3</b></a></li> 3606 3619 <li><tt>extension-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> 3607 <li><tt>From</tt> <a href="#rfc.iref.g. 29"><b>9.4</b></a></li>3620 <li><tt>From</tt> <a href="#rfc.iref.g.31"><b>10.4</b></a></li> 3608 3621 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b>8</b></a></li> 3609 3622 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b>8</b></a></li> 3610 3623 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b>8</b></a></li> 3611 <li><tt>Location</tt> <a href="#rfc.iref.g.3 0"><b>9.5</b></a></li>3612 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.3 1"><b>9.6</b></a></li>3624 <li><tt>Location</tt> <a href="#rfc.iref.g.32"><b>10.5</b></a></li> 3625 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.33"><b>10.6</b></a></li> 3613 3626 <li><tt>Method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 3614 3627 <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b>8</b></a></li> 3615 3628 <li><tt>month</tt> <a href="#rfc.iref.g.16"><b>8</b></a></li> 3616 3629 <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b>8</b></a></li> 3630 <li><tt>product</tt> <a href="#rfc.iref.g.22"><b>9</b></a></li> 3631 <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b>9</b></a></li> 3617 3632 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> 3618 <li><tt>Referer</tt> <a href="#rfc.iref.g.3 2"><b>9.7</b></a></li>3619 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.3 3"><b>9.8</b></a></li>3633 <li><tt>Referer</tt> <a href="#rfc.iref.g.34"><b>10.7</b></a></li> 3634 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.35"><b>10.8</b></a></li> 3620 3635 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b>8</b></a></li> 3621 3636 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b>8</b></a></li> 3622 3637 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b>8</b></a></li> 3623 <li><tt>Server</tt> <a href="#rfc.iref.g.3 5"><b>9.9</b></a></li>3638 <li><tt>Server</tt> <a href="#rfc.iref.g.37"><b>10.9</b></a></li> 3624 3639 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.2"><b>4</b></a></li> 3625 3640 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b>8</b></a></li> 3626 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.3 6"><b>9.10</b></a></li>3641 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.38"><b>10.10</b></a></li> 3627 3642 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b>8</b></a></li> 3628 3643 </ul> … … 3631 3646 </li> 3632 3647 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 3633 <li>HEAD method <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">1 0.1</a></li>3648 <li>HEAD method <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> 3634 3649 <li>Header Fields 3635 3650 <ul> 3636 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b> 9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>3637 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b> 9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>3638 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.h.4"><b> 9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>3639 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b> 9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>3640 <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b> 9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>3641 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b> 9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3642 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b> 9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3643 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.9"><b> 9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>3644 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b> 9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>3645 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b> 9.10</b></a>, <a href="#rfc.xref.header.user-agent.2">10.3</a>, <a href="#rfc.xref.header.user-agent.3">11.1</a></li>3651 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3652 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li> 3653 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3654 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> 3655 <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 3656 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3657 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3658 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li> 3659 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3660 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>10.10</b></a>, <a href="#rfc.xref.header.user-agent.2">11.3</a>, <a href="#rfc.xref.header.user-agent.3">12.1</a></li> 3646 3661 </ul> 3647 3662 </li> … … 3653 3668 </li> 3654 3669 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 3655 <li>Location header field <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b> 9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>3670 <li>Location header field <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 3656 3671 </ul> 3657 3672 </li> 3658 3673 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 3659 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b> 9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3674 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3660 3675 <li>Methods 3661 3676 <ul> 3662 <li>CONNECT <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">1 0.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>3663 <li>DELETE <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">1 0.1</a></li>3664 <li>GET <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">1 0.1</a></li>3665 <li>HEAD <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">1 0.1</a></li>3666 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2"> 9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>3667 <li>POST <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">1 0.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3668 <li>PUT <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">1 0.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>3669 <li>TRACE <a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2"> 9.6</a>, <a href="#rfc.xref.TRACE.3">10.1</a>, <a href="#rfc.xref.TRACE.4">11.1</a></li>3677 <li>CONNECT <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li> 3678 <li>DELETE <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> 3679 <li>GET <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> 3680 <li>HEAD <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> 3681 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> 3682 <li>POST <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li> 3683 <li>PUT <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li> 3684 <li>TRACE <a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">10.6</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 3670 3685 </ul> 3671 3686 </li> … … 3673 3688 </li> 3674 3689 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3675 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2"> 9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>3690 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> 3676 3691 </ul> 3677 3692 </li> 3678 3693 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3679 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15"> 1.2.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.28">5.1</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.15</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">9.10</a>, <a href="#rfc.xref.Part1.44">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.45">A</a><ul>3694 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.15</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">10.3</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a>, <a href="#rfc.xref.Part1.41">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.42">A</a><ul> 3680 3695 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3681 3696 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3682 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.3 4">7.2.4</a></li>3683 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 7">7.5.6</a></li>3684 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.1 5">1.2.2</a></li>3685 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.3 1">6.9</a></li>3697 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.33">7.2.4</a></li> 3698 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">7.5.6</a></li> 3699 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3700 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li> 3686 3701 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 3687 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">9.10</a></li> 3688 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.20">3.1</a></li> 3689 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.19">3.1</a></li> 3690 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 3691 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.28">5.1</a></li> 3692 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.23">3.1</a></li> 3693 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 3694 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">9.3</a></li> 3695 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3696 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3697 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.25">3.2</a></li> 3698 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li> 3699 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.45">A</a></li> 3700 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.30">6.8</a></li> 3701 <li><em>Section 11</em> <a href="#rfc.xref.Part1.44">12</a></li> 3702 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a></li> 3703 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 3704 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3705 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> 3706 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3707 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3708 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3709 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li> 3710 <li><em>Section 9.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3711 <li><em>Section 9.2</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3712 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li> 3713 <li><em>Section 9.4</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li> 3714 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> 3715 <li><em>Section 12</em> <a href="#rfc.xref.Part1.41">13</a></li> 3702 3716 </ul> 3703 3717 </li> 3704 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13"> 9.5</a>, <a href="#Part3"><b>13.1</b></a><ul>3718 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13">10.5</a>, <a href="#Part3"><b>14.1</b></a><ul> 3705 3719 <li><em>Section 2.3</em> <a href="#rfc.xref.Part3.2">3.1</a></li> 3706 3720 <li><em>Section 5</em> <a href="#rfc.xref.Part3.11">7.3.1</a></li> … … 3711 3725 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.5">3.2</a></li> 3712 3726 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.6">3.2</a></li> 3713 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.13"> 9.5</a></li>3727 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.13">10.5</a></li> 3714 3728 <li><em>Section 6.8</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.9">7</a></li> 3715 3729 </ul> 3716 3730 </li> 3717 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>1 3.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>3731 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul> 3718 3732 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li> 3719 3733 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> … … 3726 3740 </ul> 3727 3741 </li> 3728 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>1 3.1</b></a><ul>3742 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>14.1</b></a><ul> 3729 3743 <li><em>Section 3</em> <a href="#rfc.xref.Part5.4">4.1</a></li> 3730 3744 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.5">4.1</a></li> … … 3735 3749 </ul> 3736 3750 </li> 3737 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>1 3.1</b></a><ul>3751 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>14.1</b></a><ul> 3738 3752 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.8">6.5</a></li> 3739 3753 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a></li> … … 3745 3759 </ul> 3746 3760 </li> 3747 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>1 3.1</b></a><ul>3761 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>14.1</b></a><ul> 3748 3762 <li><em>Section 3</em> <a href="#rfc.xref.Part7.5">4.1</a></li> 3749 3763 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.6">4.1</a></li> … … 3755 3769 </ul> 3756 3770 </li> 3757 <li>POST method <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">1 0.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3758 <li>PUT method <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">1 0.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>3771 <li>POST method <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li> 3772 <li>PUT method <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li> 3759 3773 </ul> 3760 3774 </li> 3761 3775 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 3762 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b> 9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3763 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b> 9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>3764 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">8</a>, <a href="#rfc.xref.RFC1123.2">8</a>, <a href="#RFC1123"><b>1 3.2</b></a><ul>3776 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3777 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li> 3778 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">8</a>, <a href="#rfc.xref.RFC1123.2">8</a>, <a href="#RFC1123"><b>14.2</b></a><ul> 3765 3779 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">8</a></li> 3766 3780 </ul> 3767 3781 </li> 3768 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">7.3</a>, <a href="#RFC1945"><b>1 3.2</b></a><ul>3782 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">7.3</a>, <a href="#RFC1945"><b>14.2</b></a><ul> 3769 3783 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">7.3</a></li> 3770 3784 </ul> 3771 3785 </li> 3772 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>1 3.2</b></a><ul>3786 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>14.2</b></a><ul> 3773 3787 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">7.3</a></li> 3774 3788 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">7.3</a></li> 3775 3789 </ul> 3776 3790 </li> 3777 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>1 3.1</b></a></li>3778 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7.3</a>, <a href="#RFC2616"><b>1 3.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>3791 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>14.1</b></a></li> 3792 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7.3</a>, <a href="#RFC2616"><b>14.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul> 3779 3793 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">7.3</a></li> 3780 3794 </ul> 3781 3795 </li> 3782 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">1 0.2</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>3783 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">1 0.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li>3796 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#RFC2817"><b>14.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul> 3797 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li> 3784 3798 </ul> 3785 3799 </li> 3786 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">1 0.3</a>, <a href="#RFC3864"><b>13.2</b></a><ul>3800 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">11.3</a>, <a href="#RFC3864"><b>14.2</b></a><ul> 3787 3801 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> 3788 3802 </ul> 3789 3803 </li> 3790 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1"> 9.5</a>, <a href="#rfc.xref.RFC3986.2">9.5</a>, <a href="#RFC3986"><b>13.1</b></a><ul>3791 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1"> 9.5</a></li>3792 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2"> 9.5</a></li>3804 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">10.5</a>, <a href="#rfc.xref.RFC3986.2">10.5</a>, <a href="#RFC3986"><b>14.1</b></a><ul> 3805 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">10.5</a></li> 3806 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">10.5</a></li> 3793 3807 </ul> 3794 3808 </li> 3795 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>1 3.2</b></a><ul>3809 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>14.2</b></a><ul> 3796 3810 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a></li> 3797 3811 </ul> 3798 3812 </li> 3799 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>1 3.1</b></a><ul>3813 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>14.1</b></a><ul> 3800 3814 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 3801 3815 </ul> 3802 3816 </li> 3803 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">8</a>, <a href="#rfc.xref.RFC5322.2"> 9.2</a>, <a href="#rfc.xref.RFC5322.3">9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a>, <a href="#RFC5322"><b>13.2</b></a><ul>3817 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">8</a>, <a href="#rfc.xref.RFC5322.2">10.2</a>, <a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a>, <a href="#RFC5322"><b>14.2</b></a><ul> 3804 3818 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">8</a></li> 3805 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3"> 9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a></li>3806 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2"> 9.2</a></li>3819 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a></li> 3820 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">10.2</a></li> 3807 3821 </ul> 3808 3822 </li> 3809 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>1 3.2</b></a></li>3810 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>1 3.2</b></a></li>3823 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>14.2</b></a></li> 3824 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>14.2</b></a></li> 3811 3825 </ul> 3812 3826 </li> 3813 3827 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 3814 3828 <li>Safe Methods <a href="#rfc.iref.s.1"><b>6.1.1</b></a></li> 3815 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b> 9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>3829 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3816 3830 <li>Status Codes 3817 3831 <ul> 3818 <li>100 Continue <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.2"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">1 0.2</a></li>3819 <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.3"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">1 0.2</a></li>3820 <li>200 OK <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">1 0.2</a></li>3821 <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">1 0.2</a></li>3822 <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">1 0.2</a></li>3823 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">1 0.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3824 <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">1 0.2</a></li>3825 <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">1 0.2</a></li>3826 <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.10"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">1 0.2</a></li>3827 <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.11"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">1 0.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3828 <li>302 Found <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.12"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">1 0.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3829 <li>303 See Other <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.13"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">1 0.2</a></li>3830 <li>305 Use Proxy <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.14"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">1 0.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3831 <li>306 (Unused) <a href="#rfc.iref.s.15"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">1 0.2</a></li>3832 <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.16"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">1 0.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>3833 <li>400 Bad Request <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.17"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">1 0.2</a></li>3834 <li>402 Payment Required <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.18"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">1 0.2</a></li>3835 <li>403 Forbidden <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.19"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">1 0.2</a></li>3836 <li>404 Not Found <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.20"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">1 0.2</a></li>3837 <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.21"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">1 0.2</a></li>3838 <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.22"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">1 0.2</a></li>3839 <li>408 Request Timeout <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.23"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">1 0.2</a></li>3840 <li>409 Conflict <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.24"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">1 0.2</a></li>3841 <li>410 Gone <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.25"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">1 0.2</a></li>3842 <li>411 Length Required <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.26"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">1 0.2</a></li>3843 <li>413 Request Representation Too Large <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.27"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">1 0.2</a></li>3844 <li>414 URI Too Long <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.28"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">1 0.2</a></li>3845 <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.29"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">1 0.2</a></li>3846 <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.30"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">1 0.2</a></li>3847 <li>426 Upgrade Required <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.31"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">1 0.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>3848 <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.32"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">1 0.2</a></li>3849 <li>501 Not Implemented <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.33"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">1 0.2</a></li>3850 <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.34"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">1 0.2</a></li>3851 <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.35"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">1 0.2</a></li>3852 <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.36"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">1 0.2