Changeset 2031 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 05/12/12 16:59:49 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2030 r2031 449 449 } 450 450 @bottom-center { 451 content: "Expires June 7, 2013";451 content: "Expires June 8, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 4">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-05"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 4, 2012</td>522 <td class="right">December 5, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 7, 2013</td>525 <td class="left">Expires: June 8, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 7, 2013.</p>553 <p>This Internet-Draft will expire on June 8, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 635 635 <li><a href="#rfc.section.5.4">5.4</a> <a href="#header.host">Host</a></li> 636 636 <li><a href="#rfc.section.5.5">5.5</a> <a href="#effective.request.uri">Effective Request URI</a></li> 637 <li><a href="#rfc.section.5.6">5.6</a> <a href="#message.forwarding">Message Forwarding</a></li> 638 <li><a href="#rfc.section.5.7">5.7</a> <a href="#header.via">Via</a></li> 639 <li><a href="#rfc.section.5.8">5.8</a> <a href="#message.transforming">Message Transforming</a></li> 640 <li><a href="#rfc.section.5.9">5.9</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 637 <li><a href="#rfc.section.5.6">5.6</a> <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 638 <li><a href="#rfc.section.5.7">5.7</a> <a href="#message.forwarding">Message Forwarding</a><ul> 639 <li><a href="#rfc.section.5.7.1">5.7.1</a> <a href="#header.via">Via</a></li> 640 <li><a href="#rfc.section.5.7.2">5.7.2</a> <a href="#message.transformation">Transformation</a></li> 641 </ul> 642 </li> 641 643 </ul> 642 644 </li> … … 893 895 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 894 896 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 895 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 <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7 </a>) header fields for both connections.897 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 <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7.1</a>) header fields for both connections. 896 898 </p> 897 899 <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 … … 1345 1347 </p> 1346 1348 <div id="rfc.iref.t.4"></div> 1349 <div id="rfc.iref.c.6"></div> 1347 1350 <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> 1348 <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header 1349 field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined 1350 in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. 1351 <p id="rfc.section.3.3.1.p.1">The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that 1352 have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. 1351 1353 </p> 1352 1354 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> … … 1354 1356 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's case, Transfer-Encoding is 1355 1357 primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only 1356 applied for transport efficiency or security from those that are characteristics of the target resource. 1357 </p> 1358 <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size 1359 is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding 1360 applied <em class="bcp14">MUST</em> be "chunked". If any 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. 1358 applied for transport efficiency or security from those that are characteristics of the selected resource. 1359 </p> 1360 <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> implement the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. If chunked is applied 1361 to a payload body, the sender <em class="bcp14">MUST NOT</em> apply chunked more than once (i.e., chunking an already chunked message is not allowed). If any transfer coding is applied 1362 to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding is applied 1363 to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection. 1361 1364 </p> 1362 1365 <div id="rfc.figure.u.27"></div> … … 1365 1368 forming the message body. 1366 1369 </p> 1367 <p id="rfc.section.3.3.1.p.6">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. 1368 </p> 1369 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), 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. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1370 </p> 1371 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer 1370 <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and any recipient along the request/response chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding 1371 changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1372 </p> 1373 <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer 1372 1374 coding to the message body if the request had been an unconditional GET. This indication is not required, however, because 1373 1375 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. 1374 1376 </p> 1375 <p id="rfc.section.3.3.1.p. 9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will1377 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will 1376 1378 not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge 1377 1379 might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). 1378 1380 </p> 1379 <p id="rfc.section.3.3.1.p. 10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> and then close the connection.1380 </p> 1381 <div id="rfc.iref.c. 6"></div>1381 <p id="rfc.section.3.3.1.p.9">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>. 1382 </p> 1383 <div id="rfc.iref.c.7"></div> 1382 1384 <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> 1383 1385 <p id="rfc.section.3.3.2.p.1">When a message is allowed to contain a message body, does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, and has a payload body length that is known to the sender before the message header section has been sent, the … … 1411 1413 </p> 1412 1414 </div> 1415 <div id="rfc.iref.c.8"></div> 1413 1416 <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> 1414 1417 <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p> … … 1426 1429 </li> 1427 1430 <li> 1428 <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding1429 indicates the data is complete.1431 <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer 1432 coding indicates the data is complete. 1430 1433 </p> 1431 <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the "chunked" transfer-coding is not the final encoding, the message body length 1432 is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in 1433 a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably; 1434 the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. 1434 <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is 1435 determined by reading the connection until it is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot 1436 be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. 1435 1437 </p> 1436 1438 <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request 1437 1439 or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an 1438 error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding 1439 is decoded. 1440 error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream. 1440 1441 </p> 1441 1442 </li> … … 1468 1469 <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 <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>. 1469 1470 </p> 1470 <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 <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the "chunked" encoding, since some existing services1471 respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via1472 a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire1473 request before processing.1471 <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 <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing 1472 services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically because such services are implemented 1473 via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the 1474 entire request before processing. 1474 1475 </p> 1475 1476 <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 <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of … … 1477 1478 </p> 1478 1479 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2> 1479 <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. 1480 </p> 1481 <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number 1482 of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) 1483 cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. 1484 </p> 1485 <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding 1486 has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response 1487 that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered 1480 <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection. 1481 </p> 1482 <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding 1483 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. If a response terminates in the middle of the header block (before the empty line is received) 1484 and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume 1485 that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next. 1486 </p> 1487 <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has 1488 not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response 1489 that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered 1488 1490 complete regardless of the number of message body octets received, provided that the header block was received intact. 1489 1491 </p> … … 1496 1498 </p> 1497 1499 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> 1498 <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server1499 applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then1500 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.1501 </p> 1502 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if theserver is reading the protocol1503 stream at the beginning of a message and receives a CRLF first, it<em class="bcp14">SHOULD</em> ignore the CRLF.1500 <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a lame workaround for some early 1501 server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then 1502 the user agent <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length. 1503 </p> 1504 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol 1505 stream at the beginning of a message and receives a CRLF first, the server <em class="bcp14">SHOULD</em> ignore the CRLF. 1504 1506 </p> 1505 1507 <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR. … … 1515 1517 </p> 1516 1518 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1> 1517 <p id="rfc.section.4.p.1">Transfer -coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied1518 to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the1519 transfer-coding is a property of the message rather than a property of the representation that is being transferred.1519 <p id="rfc.section.4.p.1">Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to 1520 a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer 1521 coding is a property of the message rather than a property of the representation that is being transferred. 1520 1522 </p> 1521 1523 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> … … 1531 1533 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1532 1534 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1533 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>) header fields.1534 </p> 1535 <div id="rfc.iref.c. 7"></div>1535 </pre><p id="rfc.section.4.p.5">All transfer-coding names are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>) header fields. 1536 </p> 1537 <div id="rfc.iref.c.9"></div> 1536 1538 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2> 1537 <p id="rfc.section.4.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 size1538 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary1539 <p id="rfc.section.4.1.p.1">The chunked transfer coding modifies the body of a message in order to transfer it as a series of chunks, each with its own 1540 size indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary 1539 1541 for the recipient to verify that it has received the full message. 1540 1542 </p> … … 1558 1560 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1559 1561 <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> 1560 </pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chucked encoding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged. 1561 </p> 1562 <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1563 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1562 </pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chunked transfer coding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged. 1563 </p> 1564 <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding 1565 is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer, and finally terminated by 1566 an empty line. 1564 1567 </p> 1565 1568 <div id="rfc.iref.t.5"></div> … … 1569 1572 status. The trailer <em class="bcp14">MUST NOT</em> contain fields that need to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>. 1570 1573 </p> 1571 <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer -coding and the sender desires to send metadata in1574 <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in 1572 1575 the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> send a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to 1573 1576 prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed … … 1577 1580 </pre><p id="rfc.section.4.1.1.p.4">If no <a href="#header.trailer" class="smpl">Trailer</a> header field is present, the sender of a chunked message body <em class="bcp14">SHOULD</em> send an empty trailer. 1578 1581 </p> 1579 <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer -coding unless at least one of the following is true:1582 <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer coding unless at least one of the following is true: 1580 1583 </p> 1581 1584 <ol> 1582 <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer -coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>; or,1585 <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>; or, 1583 1586 </li> 1584 1587 <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to … … 1591 1594 </p> 1592 1595 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="decoding.chunked" href="#decoding.chunked">Decoding chunked</a></h3> 1593 <p id="rfc.section.4.1.2.p.1">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>1596 <p id="rfc.section.4.1.2.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p> 1594 1597 <div id="rfc.figure.u.34"></div><pre class="text"> length := 0 1595 1598 read chunk-size, chunk-ext (if any) and CRLF … … 1608 1611 Remove "chunked" from Transfer-Encoding 1609 1612 Remove Trailer from existing header fields 1610 </pre><p id="rfc.section.4.1.2.p.3">All recipients <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.1613 </pre><p id="rfc.section.4.1.2.p.3">All recipients <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. 1611 1614 </p> 1612 1615 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h2> 1613 1616 <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p> 1614 <div id="rfc.iref.c. 8"></div>1617 <div id="rfc.iref.c.10"></div> 1615 1618 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h3> 1616 1619 <p id="rfc.section.4.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 … … 1631 1634 <div id="rfc.iref.t.6"></div> 1632 1635 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="header.te" href="#header.te">TE</a></h2> 1633 <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer -codings, besides "chunked", the client is willing to accept in1634 response, and whether or not the client is willing to accept trailer fields in a chunked transfer-coding.1635 </p> 1636 <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer -coding names, each allowing for optional parameters (as1637 described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer -coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.1636 <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response, 1637 and whether or not the client is willing to accept trailer fields in a chunked transfer coding. 1638 </p> 1639 <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as 1640 described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. 1638 1641 </p> 1639 1642 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> … … 1646 1649 TE: 1647 1650 TE: trailers, deflate;q=0.5 1648 </pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer -coding,1649 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients1651 </pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer 1652 coding, as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients 1650 1653 are willing to accept trailer fields in the forwarded response; or, (b) the client will attempt to buffer the response on 1651 1654 behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response such 1652 1655 that a client can be assured of buffering the entire response. 1653 1656 </p> 1654 <p id="rfc.section.4.3.p.7">When multiple transfer -codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation1657 <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation 1655 1658 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; 1656 1659 a value of 0 means "not acceptable". 1657 1660 </p> 1658 <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer -coding is "chunked". A message with1659 no transfer -coding is always acceptable.1661 <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with 1662 no transfer coding is always acceptable. 1660 1663 </p> 1661 1664 <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics. … … 1725 1728 <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in absolute-form as the request-target. The proxy is requested to either service that request from a valid 1726 1729 cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to 1727 the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section 5. 6</a>.1730 the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section 5.7</a>. 1728 1731 </p> 1729 1732 </div> … … 1817 1820 the effective request URI's authority component. 1818 1821 </p> 1819 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2> 1820 <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used 1822 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1823 <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1824 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1825 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. 1826 </p> 1827 <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final 1828 (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. 1829 </p> 1830 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2> 1831 <p id="rfc.section.5.7.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section 2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used 1821 1832 to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has 1822 1833 characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can 1823 1834 enhance (or interfere) with either direction of the stream. 1824 1835 </p> 1825 <p id="rfc.section.5. 6.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 6.1</a>, to exclude fields that are only intended for the incoming connection.1826 </p> 1827 <p id="rfc.section.5. 6.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.1836 <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 6.1</a>, to exclude fields that are only intended for the incoming connection. 1837 </p> 1838 <p id="rfc.section.5.7.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. 1828 1839 </p> 1829 1840 <div id="rfc.iref.v.1"></div> 1830 <h 2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.via" href="#header.via">Via</a></h2>1831 <p id="rfc.section.5.7. p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway in forwarded messages to indicate the intermediate protocols and recipients between the user1841 <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a> <a id="header.via" href="#header.via">Via</a></h3> 1842 <p id="rfc.section.5.7.1.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway in forwarded messages to indicate the intermediate protocols and recipients between the user 1832 1843 agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" 1833 1844 field used by email 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>). Via is used in HTTP for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of … … 1840 1851 <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> 1841 1852 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 1842 </pre><p id="rfc.section.5.7. p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of1853 </pre><p id="rfc.section.5.7.1.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 1843 1854 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 1844 1855 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 1845 1856 </p> 1846 <p id="rfc.section.5.7. 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 port1857 <p id="rfc.section.5.7.1.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 1847 1858 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 1848 1859 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. 1849 1860 </p> 1850 <p id="rfc.section.5.7. 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.1851 </p> 1852 <p id="rfc.section.5.7. 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 <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header 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.1853 </p> 1854 <p id="rfc.section.5.7. 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 uses1861 <p id="rfc.section.5.7.1.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. 1862 </p> 1863 <p id="rfc.section.5.7.1.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 <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header 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. 1864 </p> 1865 <p id="rfc.section.5.7.1.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 1855 1866 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 1856 1867 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1857 1868 </p> 1858 1869 <div id="rfc.figure.u.52"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1859 </pre><p id="rfc.section.5.7. 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,1870 </pre><p id="rfc.section.5.7.1.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, 1860 1871 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1861 1872 </p> 1862 <p id="rfc.section.5.7. p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol1873 <p id="rfc.section.5.7.1.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol 1863 1874 values. For example, 1864 1875 </p> 1865 1876 <div id="rfc.figure.u.53"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1866 </pre><p id="rfc.section.5.7. p.12">could be collapsed to</p>1877 </pre><p id="rfc.section.5.7.1.p.12">could be collapsed to</p> 1867 1878 <div id="rfc.figure.u.54"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1868 </pre><p id="rfc.section.5.7. 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 replaced1879 </pre><p id="rfc.section.5.7.1.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 1869 1880 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 1870 1881 </p> 1871 <h 2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="message.transforming" href="#message.transforming">Message Transforming</a></h2>1872 <p id="rfc.section.5. 8.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.1873 </p> 1874 <p id="rfc.section.5. 8.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,1882 <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a id="message.transformation" href="#message.transformation">Transformation</a></h3> 1883 <p id="rfc.section.5.7.2.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. 1884 </p> 1885 <p id="rfc.section.5.7.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1875 1886 except as noted above to replace an empty path with "/" or "*". 1876 1887 </p> 1877 <p id="rfc.section.5. 8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</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 4</a>).1878 </p> 1879 <p id="rfc.section.5. 8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the1888 <p id="rfc.section.5.7.2.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</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 4</a>). 1889 </p> 1890 <p id="rfc.section.5.7.2.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the 1880 1891 selected representation. 1881 1892 </p> 1882 <p id="rfc.section.5. 8.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:1893 <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 1883 1894 </p> 1884 1895 <ul> 1885 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.2 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)1886 </li> 1887 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)1896 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1897 </li> 1898 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1888 1899 </li> 1889 1900 <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) … … 1893 1904 <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) 1894 1905 </li> 1895 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)1906 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1896 1907 </li> 1897 1908 </ul> 1898 <p id="rfc.section.5. 8.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.1899 </p> 1900 <p id="rfc.section.5. 8.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:1909 <p id="rfc.section.5.7.2.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field. 1910 </p> 1911 <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive: 1901 1912 </p> 1902 1913 <ul> 1903 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)1914 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1904 1915 </li> 1905 1916 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) 1906 1917 </li> 1907 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.2 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)1918 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1908 1919 </li> 1909 1920 </ul> 1910 <p id="rfc.section.5. 8.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1911 </p> 1912 <div class="note" id="rfc.section.5. 8.p.9">1921 <p id="rfc.section.5.7.2.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1922 </p> 1923 <div class="note" id="rfc.section.5.7.2.p.9"> 1913 1924 <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced 1914 1925 in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 1915 1926 </p> 1916 1927 </div> 1917 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>1918 <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response1919 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made1920 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.1921 </p>1922 <p id="rfc.section.5.9.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-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.1923 </p>1924 1928 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connection.management" href="#connection.management">Connection Management</a></h1> 1925 1929 <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable … … 1936 1940 queues to enable fair use and detect denial of service attacks. 1937 1941 </p> 1938 <div id="rfc.iref.c. 9"></div>1939 <div id="rfc.iref.c.1 0"></div>1942 <div id="rfc.iref.c.11"></div> 1943 <div id="rfc.iref.c.12"></div> 1940 1944 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1941 1945 <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to … … 2080 2084 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection. 2081 2085 </p> 2082 <div id="rfc.iref.c.1 1"></div>2083 <div id="rfc.iref.c.1 2"></div>2086 <div id="rfc.iref.c.13"></div> 2087 <div id="rfc.iref.c.14"></div> 2084 2088 <h3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h3> 2085 2089 <p id="rfc.section.6.2.5.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. … … 2216 2220 <td class="left">http</td> 2217 2221 <td class="left">standard</td> 2218 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7 </a>2222 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7.1</a> 2219 2223 </td> 2220 2224 </tr> … … 2836 2840 </p> 2837 2841 <h3 id="rfc.section.A.1.3"><a href="#rfc.section.A.1.3">A.1.3</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3> 2838 <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 3.3.1</a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer -coding prior to forwarding a message via a MIME-compliant protocol.2842 <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 3.3.1</a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer coding prior to forwarding a message via a MIME-compliant protocol. 2839 2843 </p> 2840 2844 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 2877 2881 <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) 2878 2882 </p> 2879 <p id="rfc.section.A.2.p.18">The "identity" transfer -coding valuetoken has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)2883 <p id="rfc.section.A.2.p.18">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) 2880 2884 </p> 2881 2885 <p id="rfc.section.A.2.p.19">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven … … 3106 3110 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3107 3111 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3108 <li>chunked (Coding Format) <a href="#rfc.iref.c. 7">4.1</a></li>3112 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li> 3109 3113 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3110 <li>close <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5. 6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3111 <li>compress (Coding Format) <a href="#rfc.iref.c. 8">4.2.1</a></li>3114 <li>close <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3115 <li>compress (Coding Format) <a href="#rfc.iref.c.10">4.2.1</a></li> 3112 3116 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3113 <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5. 6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3114 <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">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>3117 <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.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3118 <li>Content-Length header field <a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li> 3115 3119 </ul> 3116 3120 </li> … … 3179 3183 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3180 3184 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3181 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>5.7 </b></a></li>3182 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>5.7 </b></a></li>3183 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>5.7 </b></a></li>3185 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>5.7.1</b></a></li> 3186 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>5.7.1</b></a></li> 3187 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>5.7.1</b></a></li> 3184 3188 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.6</b></a></li> 3185 3189 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> … … 3191 3195 <li><tt>rank</tt> <a href="#rfc.iref.g.78"><b>4.3</b></a></li> 3192 3196 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3193 <li><tt>received-by</tt> <a href="#rfc.iref.g.89"><b>5.7 </b></a></li>3194 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.86"><b>5.7 </b></a></li>3197 <li><tt>received-by</tt> <a href="#rfc.iref.g.89"><b>5.7.1</b></a></li> 3198 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.86"><b>5.7.1</b></a></li> 3195 3199 <li><tt>request-line</tt> <a href="#rfc.iref.g.28"><b>3.1.1</b></a></li> 3196 3200 <li><tt>request-target</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> … … 3217 3221 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3218 3222 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3219 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>5.7 </b></a></li>3223 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>5.7.1</b></a></li> 3220 3224 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2.6</b></a></li> 3221 3225 </ul> … … 3267 3271 </li> 3268 3272 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3269 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5. 8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3273 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3270 3274 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3271 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.2 5">5.8</a></li>3275 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.26">5.7.2</a></li> 3272 3276 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">7.4</a></li> 3273 <li><em>Section 3.1.2.2</em> <a href="#rfc.xref.Part2.2 4">5.8</a></li>3274 <li><em>Section 3.1.4.2</em> <a href="#rfc.xref.Part2.2 2">5.8</a></li>3275 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.2 0">5.8</a></li>3277 <li><em>Section 3.1.2.2</em> <a href="#rfc.xref.Part2.25">5.7.2</a></li> 3278 <li><em>Section 3.1.4.2</em> <a href="#rfc.xref.Part2.23">5.7.2</a></li> 3279 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.21">5.7.2</a></li> 3276 3280 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3277 3281 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a></li> … … 3281 3285 <li><em>Section 6.3.1</em> <a href="#rfc.xref.Part2.16">4.3</a></li> 3282 3286 <li><em>Section 7</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li> 3283 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.2 6">5.9</a></li>3287 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.20">5.6</a></li> 3284 3288 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3285 3289 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.29">6.3</a></li> … … 3287 3291 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li> 3288 3292 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3289 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.2 1">5.8</a></li>3290 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.2 3">5.8</a></li>3293 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.22">5.7.2</a></li> 3294 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.24">5.7.2</a></li> 3291 3295 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3292 3296 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3293 3297 </ul> 3294 3298 </li> 3295 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5. 8</a>, <a href="#rfc.xref.Part4.5">5.8</a>, <a href="#Part4"><b>10.1</b></a><ul>3296 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5. 8</a></li>3297 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5. 8</a></li>3299 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.7.2</a>, <a href="#rfc.xref.Part4.5">5.7.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3300 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5.7.2</a></li> 3301 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5.7.2</a></li> 3298 3302 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li> 3299 3303 </ul> 3300 3304 </li> 3301 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5. 8</a>, <a href="#Part5"><b>10.1</b></a><ul>3302 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5. 8</a></li>3305 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.7.2</a>, <a href="#Part5"><b>10.1</b></a><ul> 3306 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5.7.2</a></li> 3303 3307 </ul> 3304 3308 </li> 3305 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5. 8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>3309 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.7.2</a>, <a href="#rfc.xref.Part6.8">5.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3306 3310 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2.4</a></li> 3307 3311 <li><em>Section 3</em> <a href="#rfc.xref.Part6.5">3.4</a></li> 3308 3312 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li> 3309 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5. 8</a></li>3310 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5. 8</a></li>3313 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5.7.2</a></li> 3314 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.7.2</a></li> 3311 3315 </ul> 3312 3316 </li> … … 3338 3342 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3339 3343 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3340 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5. 8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul>3341 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5. 8</a></li>3344 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.7.2</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul> 3345 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5.7.2</a></li> 3342 3346 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> 3343 3347 </ul> … … 3381 3385 </li> 3382 3386 <li><em>RFC5246</em> <a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#rfc.xref.RFC5246.2">2.7.2</a>, <a href="#RFC5246"><b>10.2</b></a></li> 3383 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7 </a>, <a href="#RFC5322"><b>10.2</b></a><ul>3384 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">5.7 </a></li>3387 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7.1</a>, <a href="#RFC5322"><b>10.2</b></a><ul> 3388 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">5.7.1</a></li> 3385 3389 </ul> 3386 3390 </li> … … 3406 3410 </li> 3407 3411 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3408 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7 </a>, <a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3412 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3409 3413 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3410 3414 <li>URI scheme … … 3419 3423 </li> 3420 3424 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3421 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7 </b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>3425 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3422 3426 </ul> 3423 3427 </li>
Note: See TracChangeset
for help on using the changeset viewer.