Changeset 2031
- Timestamp:
- 05/12/12 16:59:49 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 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> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2030 r2031 1478 1478 <section title="Transfer-Encoding" anchor="header.transfer-encoding"> 1479 1479 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/> 1480 <iref item="chunked (Coding Format)"/> 1480 1481 <x:anchor-alias value="Transfer-Encoding"/> 1481 1482 <t> 1482 When one or more transfer codings are applied to a payload body in order 1483 to form the message body, a Transfer-Encoding header field &MUST; be sent 1484 in the message and &MUST; contain the list of corresponding 1485 transfer-coding names in the same order that they were applied. 1483 The Transfer-Encoding header field lists the transfer coding names 1484 corresponding to the sequence of transfer codings that have been 1485 (or will be) applied to the payload body in order to form the message body. 1486 1486 Transfer codings are defined in <xref target="transfer.codings"/>. 1487 1487 </t> … … 1497 1497 accurately delimit a dynamically generated payload and to distinguish 1498 1498 payload encodings that are only applied for transport efficiency or 1499 security from those that are characteristics of the targetresource.1500 </t> 1501 <t> 1502 The "chunked" transfer-coding (<xref target="chunked.encoding"/>)1503 &MUST; be implemented by all HTTP/1.1 recipients because it plays a1504 crucial role in delimiting messages when the payload body size is not1505 known in advance.1506 When the "chunked" transfer-coding is used, it &MUST; be the last1507 transfer-coding applied to form the message body and &MUST-NOT;1508 be applied more than once in a message body.1509 If any transfer-coding is applied to a request payload body,1510 the final transfer-coding applied &MUST; be "chunked".1511 If any transfer -coding is applied to a response payload body, then either1512 the final transfer-coding applied &MUST; be "chunked"or1513 t he message &MUST; be terminatedby closing the connection.1499 security from those that are characteristics of the selected resource. 1500 </t> 1501 <t> 1502 All HTTP/1.1 recipients &MUST; implement the chunked transfer coding 1503 (<xref target="chunked.encoding"/>) because it plays a crucial role in 1504 framing messages when the payload body size is not known in advance. 1505 If chunked is applied to a payload body, the sender &MUST-NOT; apply 1506 chunked more than once (i.e., chunking an already chunked message is not 1507 allowed). 1508 If any transfer coding is applied to a request payload body, the 1509 sender &MUST; apply chunked as the final transfer coding to ensure that 1510 the message is properly framed. 1511 If any transfer coding is applied to a response payload body, the 1512 sender &MUST; either apply chunked as the final transfer coding or 1513 terminate the message by closing the connection. 1514 1514 </t> 1515 1515 <figure><preamble> … … 1523 1523 </postamble></figure> 1524 1524 <t> 1525 If more than one Transfer-Encoding header field is present in a message,1526 the multiple field-values &MUST; be combined into one field-value,1527 according to the algorithm defined in <xref target="header.fields"/>,1528 before determining the message body length.1529 </t>1530 <t>1531 1525 Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;), 1532 Transfer-Encoding is a property of the message, not of the payload, and thus 1533 &MAY; be added or removed by any implementation along the request/response 1534 chain. Additional information about the encoding parameters &MAY; be 1526 Transfer-Encoding is a property of the message, not of the payload, and 1527 any recipient along the request/response chain &MAY; decode the received 1528 transfer coding(s) or apply additional transfer coding(s) to the message 1529 body, assuming that corresponding changes are made to the Transfer-Encoding 1530 field-value. Additional information about the encoding parameters &MAY; be 1535 1531 provided by other header fields not defined by this specification. 1536 1532 </t> … … 1557 1553 </t> 1558 1554 <t> 1559 A server that receives a request message with a transfer-coding it does 1560 not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref> and then 1561 close the connection. 1555 A server that receives a request message with a transfer coding it does 1556 not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref>. 1562 1557 </t> 1563 1558 </section> … … 1636 1631 1637 1632 <section title="Message Body Length" anchor="message.body.length"> 1633 <iref item="chunked (Coding Format)"/> 1638 1634 <t> 1639 1635 The length of a message body is determined by one of the following … … 1659 1655 <x:lt><t> 1660 1656 If a <x:ref>Transfer-Encoding</x:ref> header field is present 1661 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)1657 and the chunked transfer coding (<xref target="chunked.encoding"/>) 1662 1658 is the final encoding, the message body length is determined by reading 1663 and decoding the chunked data until the transfer -coding indicates the1659 and decoding the chunked data until the transfer coding indicates the 1664 1660 data is complete. 1665 1661 </t> 1666 1662 <t> 1667 1663 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a 1668 response and the "chunked" transfer-coding is not the final encoding, the1664 response and the chunked transfer coding is not the final encoding, the 1669 1665 message body length is determined by reading the connection until it is 1670 1666 closed by the server. 1671 If a Transfer-Encodingheader field is present in a request and the1672 "chunked" transfer-coding is not the final encoding, the message body1667 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a request and the 1668 chunked transfer coding is not the final encoding, the message body 1673 1669 length cannot be determined reliably; the server &MUST; respond with 1674 1670 the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. … … 1676 1672 <t> 1677 1673 If a message is received with both a <x:ref>Transfer-Encoding</x:ref> 1678 and a <x:ref>Content-Length</x:ref> header field, the 1679 Transfer-Encoding overrides the Content-Length. 1680 Such a message might indicate an attempt to perform request or response 1681 smuggling (bypass of security-related checks on message routing or content) 1682 and thus ought to be handled as an error. The provided Content-Length &MUST; 1683 be removed, prior to forwarding the message downstream, or replaced with 1684 the real message body length after the transfer-coding is decoded. 1674 and a <x:ref>Content-Length</x:ref> header field, the Transfer-Encoding 1675 overrides the Content-Length. Such a message might indicate an attempt 1676 to perform request or response smuggling (bypass of security-related 1677 checks on message routing or content) and thus ought to be handled as 1678 an error. A sender &MUST; remove the received Content-Length field 1679 prior to forwarding such a message downstream. 1685 1680 </t></x:lt> 1686 1681 <x:lt><t> … … 1737 1732 </t> 1738 1733 <t> 1739 Unless a transfer -coding other than "chunked"has been applied,1734 Unless a transfer coding other than chunked has been applied, 1740 1735 a client that sends a request containing a message body &SHOULD; 1741 1736 use a valid <x:ref>Content-Length</x:ref> header field if the message body 1742 length is known in advance, rather than the "chunked" encoding, since some1743 existing services respond to "chunked"with a <x:ref>411 (Length Required)</x:ref>1744 status code even though they understand the chunked encoding. This1737 length is known in advance, rather than the chunked transfer coding, since some 1738 existing services respond to chunked with a <x:ref>411 (Length Required)</x:ref> 1739 status code even though they understand the chunked transfer coding. This 1745 1740 is typically because such services are implemented via a gateway that 1746 1741 requires a content-length in advance of being called and the server … … 1759 1754 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> 1760 1755 <t> 1761 Request messages that are prematurely terminated, possibly due to a 1762 canceled connection or a server-imposed time-out exception, &MUST; 1763 result in closure of the connection; sending an error response 1764 prior to closing the connection is &OPTIONAL;. 1765 </t> 1766 <t> 1767 Response messages that are prematurely terminated, usually by closure 1768 of the connection prior to receiving the expected number of octets or by 1769 failure to decode a transfer-encoded message body, &MUST; be recorded 1770 as incomplete. A response that terminates in the middle of the header 1771 block (before the empty line is received) cannot be assumed to convey the 1772 full semantics of the response and &MUST; be treated as an error. 1773 </t> 1774 <t> 1775 A message body that uses the chunked transfer encoding is 1756 A server that receives an incomplete request message, usually due to a 1757 canceled request or a triggered time-out exception, &MAY; send an error 1758 response prior to closing the connection. 1759 </t> 1760 <t> 1761 A client that receives an incomplete response message, which can occur 1762 when a connection is closed prematurely or when decoding a supposedly 1763 chunked transfer coding fails, &MUST; record the message as incomplete. 1764 If a response terminates in the middle of the header block (before the 1765 empty line is received) and the status code might rely on header fields to 1766 convey the full meaning of the response, then the client cannot assume 1767 that meaning has been conveyed; the client might need to repeat the 1768 request in order to determine what action to take next. 1769 </t> 1770 <t> 1771 A message body that uses the chunked transfer coding is 1776 1772 incomplete if the zero-sized chunk that terminates the encoding has not 1777 1773 been received. A message that uses a valid <x:ref>Content-Length</x:ref> is 1778 1774 incomplete if the size of the message body received (in octets) is less than 1779 1775 the value given by Content-Length. A response that has neither chunked 1780 transfer encoding nor Content-Length is terminated by closure of the1776 transfer coding nor Content-Length is terminated by closure of the 1781 1777 connection, and thus is considered complete regardless of the number of 1782 1778 message body octets received, provided that the header block was received … … 1802 1798 <section title="Message Parsing Robustness" anchor="message.robustness"> 1803 1799 <t> 1804 Older HTTP/1.0 client implementations might send an extra CRLF1800 Older HTTP/1.0 user agent implementations might send an extra CRLF 1805 1801 after a POST request as a lame workaround for some early server 1806 1802 applications that failed to read message body content that was 1807 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;1803 not terminated by a line-ending. An HTTP/1.1 user agent &MUST-NOT; 1808 1804 preface or follow a request with an extra CRLF. If terminating 1809 1805 the request message body with a line-ending is desired, then the 1810 client &MUST; include the terminating CRLF octets as part of the1806 user agent &MUST; include the terminating CRLF octets as part of the 1811 1807 message body length. 1812 1808 </t> … … 1814 1810 In the interest of robustness, servers &SHOULD; ignore at least one 1815 1811 empty line received where a request-line is expected. In other words, if 1816 theserver is reading the protocol stream at the beginning of a1817 message and receives a CRLF first, it&SHOULD; ignore the CRLF.1812 a server is reading the protocol stream at the beginning of a 1813 message and receives a CRLF first, the server &SHOULD; ignore the CRLF. 1818 1814 </t> 1819 1815 <t> … … 1845 1841 <x:anchor-alias value="transfer-extension"/> 1846 1842 <t> 1847 Transfer -coding values are used to indicate an encoding1843 Transfer coding names are used to indicate an encoding 1848 1844 transformation that has been, can be, or might need to be applied to a 1849 1845 payload body in order to ensure "safe transport" through the network. 1850 This differs from a content coding in that the transfer -coding is a1846 This differs from a content coding in that the transfer coding is a 1851 1847 property of the message rather than a property of the representation 1852 1848 that is being transferred. … … 1872 1868 </artwork></figure> 1873 1869 <t> 1874 All transfer-coding values are case-insensitive and &SHOULD; be registered1870 All transfer-coding names are case-insensitive and &SHOULD; be registered 1875 1871 within the HTTP Transfer Coding registry, as defined in 1876 1872 <xref target="transfer.coding.registry"/>. … … 1881 1877 1882 1878 <section title="Chunked Transfer Coding" anchor="chunked.encoding"> 1883 <iref item="chunked (Coding Format)"/>1879 <iref primary="true" item="chunked (Coding Format)"/> 1884 1880 <x:anchor-alias value="chunk"/> 1885 1881 <x:anchor-alias value="chunked-body"/> … … 1894 1890 <x:anchor-alias value="qdtext-nf"/> 1895 1891 <t> 1896 The chunked encoding modifies the body of a message in order to1892 The chunked transfer coding modifies the body of a message in order to 1897 1893 transfer it as a series of chunks, each with its own size indicator, 1898 1894 followed by an &OPTIONAL; trailer containing header fields. This … … 1923 1919 </artwork></figure> 1924 1920 <t> 1925 Chunk extensions within the chu cked encoding are deprecated.1921 Chunk extensions within the chunked transfer coding are deprecated. 1926 1922 Senders &SHOULD-NOT; send chunk-ext. 1927 1923 Definition of new chunk extensions is discouraged. … … 1929 1925 <t> 1930 1926 The chunk-size field is a string of hex digits indicating the size of 1931 the chunk-data in octets. The chunked encoding is ended by any chunk whose size is 1932 zero, followed by the trailer, which is terminated by an empty line. 1927 the chunk-data in octets. The chunked transfer coding is complete when a 1928 chunk with a chunk-size of zero is received, possibly followed by a 1929 trailer, and finally terminated by an empty line. 1933 1930 </t> 1934 1931 … … 1947 1944 <t> 1948 1945 When a message includes a message body encoded with the chunked 1949 transfer -coding and the sender desires to send metadata in the form of1946 transfer coding and the sender desires to send metadata in the form of 1950 1947 trailer fields at the end of the message, the sender &SHOULD; send a 1951 1948 <x:ref>Trailer</x:ref> header field before the message body to indicate … … 1963 1960 </t> 1964 1961 <t> 1965 A server &MUST; send an empty trailer with the chunked transfer -coding1962 A server &MUST; send an empty trailer with the chunked transfer coding 1966 1963 unless at least one of the following is true: 1967 1964 <list style="numbers"> 1968 1965 <t>the request included a <x:ref>TE</x:ref> header field that indicates 1969 "trailers" is acceptable in the transfer -coding of the response, as1966 "trailers" is acceptable in the transfer coding of the response, as 1970 1967 described in <xref target="header.te"/>; or,</t> 1971 1968 … … 1987 1984 <section title="Decoding chunked" anchor="decoding.chunked"> 1988 1985 <t> 1989 A process for decoding the "chunked" transfer-coding1986 A process for decoding the chunked transfer coding 1990 1987 can be represented in pseudo-code as: 1991 1988 </t> … … 2010 2007 <t> 2011 2008 All recipients &MUST; be able to receive and decode the 2012 "chunked" transfer-coding and &MUST; ignore chunk-ext extensions2009 chunked transfer coding and &MUST; ignore chunk-ext extensions 2013 2010 they do not understand. 2014 2011 </t> … … 2066 2063 <x:anchor-alias value="rank"/> 2067 2064 <t> 2068 The "TE" header field in a request indicates what transfer -codings,2069 besides "chunked", the client is willing to accept in response, and2065 The "TE" header field in a request indicates what transfer codings, 2066 besides chunked, the client is willing to accept in response, and 2070 2067 whether or not the client is willing to accept trailer fields in a 2071 chunked transfer -coding.2072 </t> 2073 <t> 2074 The TE field-value consists of a comma-separated list of transfer -coding2068 chunked transfer coding. 2069 </t> 2070 <t> 2071 The TE field-value consists of a comma-separated list of transfer coding 2075 2072 names, each allowing for optional parameters (as described in 2076 2073 <xref target="transfer.codings"/>), and/or the keyword "trailers". 2077 Clients &MUST-NOT; send the chunked transfer -coding name in TE;2074 Clients &MUST-NOT; send the chunked transfer coding name in TE; 2078 2075 chunked is always acceptable for HTTP/1.1 recipients. 2079 2076 </t> … … 2095 2092 <t> 2096 2093 The presence of the keyword "trailers" indicates that the client is 2097 willing to accept trailer fields in a chunked transfer -coding,2094 willing to accept trailer fields in a chunked transfer coding, 2098 2095 as defined in <xref target="chunked.encoding"/>, on behalf of itself and 2099 2096 any downstream clients. For chained requests, this implies that either: … … 2107 2104 </t> 2108 2105 <t> 2109 When multiple transfer -codings are acceptable, the client &MAY; rank the2106 When multiple transfer codings are acceptable, the client &MAY; rank the 2110 2107 codings by preference using a case-insensitive "q" parameter (similar to 2111 2108 the qvalues used in content negotiation fields, &qvalue;). The rank value … … 2115 2112 <t> 2116 2113 If the TE field-value is empty or if no TE field is present, the only 2117 acceptable transfer -coding is "chunked". A message with no transfer-coding2114 acceptable transfer coding is chunked. A message with no transfer coding 2118 2115 is always acceptable. 2119 2116 </t> … … 2463 2460 </section> 2464 2461 2462 <section title="Associating a Response to a Request" anchor="associating.response.to.request"> 2463 <t> 2464 HTTP does not include a request identifier for associating a given 2465 request message with its corresponding one or more response messages. 2466 Hence, it relies on the order of response arrival to correspond exactly 2467 to the order in which requests are made on the same connection. 2468 More than one response message per request only occurs when one or more 2469 informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a 2470 final response to the same request. 2471 </t> 2472 <t> 2473 A client that has more than one outstanding request on a connection &MUST; 2474 maintain a list of outstanding requests in the order sent and &MUST; 2475 associate each received response message on that connection to the highest 2476 ordered request that has not yet received a final (non-<x:ref>1xx</x:ref>) 2477 response. 2478 </t> 2479 </section> 2480 2465 2481 <section title="Message Forwarding" anchor="message.forwarding"> 2466 2482 <t> … … 2484 2500 names, including any aliases, local variations, or literal IP addresses. 2485 2501 </t> 2486 </section>2487 2502 2488 2503 <section title="Via" anchor="header.via"> … … 2579 2594 </section> 2580 2595 2581 <section title=" Message Transforming" anchor="message.transforming">2596 <section title="Transformation" anchor="message.transformation"> 2582 2597 <t> 2583 2598 If a proxy receives a request-target with a host name that is not a … … 2594 2609 A non-transforming proxy &MUST; preserve the message payload (&payload;), 2595 2610 though it &MAY; change the message body through application or removal 2596 of a transfer -coding (<xref target="transfer.codings"/>).2611 of a transfer coding (<xref target="transfer.codings"/>). 2597 2612 </t> 2598 2613 <t> … … 2645 2660 </x:note> 2646 2661 </section> 2647 2648 <section title="Associating a Response to a Request" anchor="associating.response.to.request">2649 <t>2650 HTTP does not include a request identifier for associating a given2651 request message with its corresponding one or more response messages.2652 Hence, it relies on the order of response arrival to correspond exactly2653 to the order in which requests are made on the same connection.2654 More than one response message per request only occurs when one or more2655 informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response2656 to the same request.2657 </t>2658 <t>2659 A client that uses persistent connections and sends more than one request2660 per connection &MUST; maintain a list of outstanding requests in the2661 order sent on that connection and &MUST; associate each received response2662 message to the highest ordered request that has not yet received a final2663 (non-<x:ref>1xx</x:ref>) response.2664 </t>2665 2662 </section> 2666 2663 </section> … … 4736 4733 HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field 4737 4734 (<xref target="header.transfer-encoding"/>). Proxies/gateways &MUST; remove 4738 any transfer -coding prior to forwarding a message via a MIME-compliant4735 any transfer coding prior to forwarding a message via a MIME-compliant 4739 4736 protocol. 4740 4737 </t> … … 4827 4824 </t> 4828 4825 <t> 4829 The "identity" transfer -coding valuetoken has been removed.4826 The "identity" transfer coding token has been removed. 4830 4827 (Sections <xref format="counter" target="message.body"/> and 4831 4828 <xref format="counter" target="transfer.codings"/>) -
draft-ietf-httpbis/latest/p2-semantics.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 { … … 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 4">498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-05"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">December 4, 2012</td>526 <td class="right">December 5, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 7, 2013</td>529 <td class="left">Expires: June 8, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on June 7, 2013.</p>557 <p>This Internet-Draft will expire on June 8, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1616 1616 </p> 1617 1617 <p id="rfc.section.5.3.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 1618 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7 </a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding1618 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1619 1619 messages in an infinite loop. 1620 1620 </p> … … 3092 3092 </pre><p id="rfc.section.8.4.2.p.4">Example:</p> 3093 3093 <div id="rfc.figure.u.62"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 3094 </pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7 </a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3094 </pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3095 3095 </p> 3096 3096 <div class="note" id="rfc.section.8.4.2.p.7"> … … 4155 4155 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4156 4156 </p> 4157 <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7 </a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>)4157 <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4158 4158 </p> 4159 4159 <p id="rfc.section.C.p.31">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) … … 4171 4171 <p id="rfc.section.C.p.36">The Status Code Registry is now defined by this specification; previously, it was 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.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 9.2</a>) 4172 4172 </p> 4173 <p id="rfc.section.C.p.37">References to the "identity" transfer -coding valuetoken have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>)4173 <p id="rfc.section.C.p.37">References to the "identity" transfer coding token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) 4174 4174 </p> 4175 4175 <p id="rfc.section.C.p.38">The Content-Disposition header field is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix B</a>) … … 4204 4204 <a href="#header.allow" class="smpl">Allow</a> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] 4205 4205 4206 <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 3.2. 1>4206 <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 3.2.3> 4207 4207 4208 4208 <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = *( "," OWS ) content-coding *( OWS "," [ OWS … … 4228 4228 <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT 4229 4229 4230 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2. 1>4231 4232 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in [Part1], Section 3.2. 1>4230 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2.3> 4231 4232 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in [Part1], Section 3.2.3> 4233 4233 <a href="#header.referer" class="smpl">Referer</a> = absolute-URI / partial-URI 4234 4234 <a href="#header.retry-after" class="smpl">Retry-After</a> = HTTP-date / delta-seconds … … 4250 4250 <a href="#charset" class="smpl">charset</a> = token 4251 4251 <a href="#header.accept-encoding" class="smpl">codings</a> = content-coding / "identity" / "*" 4252 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in [Part1], Section 3.2. 4>4252 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in [Part1], Section 3.2.6> 4253 4253 <a href="#content.codings" class="smpl">content-coding</a> = token 4254 4254 … … 4312 4312 <a href="#product.tokens" class="smpl">product-version</a> = token 4313 4313 4314 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2. 4>4314 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2.6> 4315 4315 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 4316 4316 … … 4322 4322 4323 4323 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second 4324 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in [Part1], Section 3.2. 4>4324 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.6> 4325 4325 <a href="#media.type" class="smpl">type</a> = token 4326 4326 … … 4328 4328 4329 4329 <a href="#quality.values" class="smpl">weight</a> = OWS ";" OWS "q=" qvalue 4330 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in [Part1], Section 3.2. 4>4330 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in [Part1], Section 3.2.6> 4331 4331 4332 4332 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT … … 4557 4557 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">6.1</a></li> 4558 4558 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.27">8</a></li> 4559 <li><em>Section 5.7 </em> <a href="#rfc.xref.Part1.17">5.3.8</a>, <a href="#rfc.xref.Part1.29">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li>4559 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.17">5.3.8</a>, <a href="#rfc.xref.Part1.29">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li> 4560 4560 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.35">9.3.1</a></li> 4561 4561 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.22">7.2.2</a>, <a href="#rfc.xref.Part1.25">7.5.15</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2030 r2031 5841 5841 </t> 5842 5842 <t> 5843 References to the "identity" transfer -coding valuetoken have been removed.5843 References to the "identity" transfer coding token have been removed. 5844 5844 (<xref target="no.content-transfer-encoding"/>) 5845 5845 </t> … … 5911 5911 <x:ref>Allow</x:ref> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] 5912 5912 5913 <x:ref>BWS</x:ref> = <BWS, defined in [Part1], Section 3.2. 1>5913 <x:ref>BWS</x:ref> = <BWS, defined in [Part1], Section 3.2.3> 5914 5914 5915 5915 <x:ref>Content-Encoding</x:ref> = *( "," OWS ) content-coding *( OWS "," [ OWS … … 5935 5935 <x:ref>Max-Forwards</x:ref> = 1*DIGIT 5936 5936 5937 <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 3.2. 1>5938 5939 <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 3.2. 1>5937 <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 3.2.3> 5938 5939 <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 3.2.3> 5940 5940 <x:ref>Referer</x:ref> = absolute-URI / partial-URI 5941 5941 <x:ref>Retry-After</x:ref> = HTTP-date / delta-seconds … … 5957 5957 <x:ref>charset</x:ref> = token 5958 5958 <x:ref>codings</x:ref> = content-coding / "identity" / "*" 5959 <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2. 4>5959 <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2.6> 5960 5960 <x:ref>content-coding</x:ref> = token 5961 5961 … … 6019 6019 <x:ref>product-version</x:ref> = token 6020 6020 6021 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 3.2. 4>6021 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 3.2.6> 6022 6022 <x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 6023 6023 … … 6029 6029 6030 6030 <x:ref>time-of-day</x:ref> = hour ":" minute ":" second 6031 <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2. 4>6031 <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2.6> 6032 6032 <x:ref>type</x:ref> = token 6033 6033 … … 6035 6035 6036 6036 <x:ref>weight</x:ref> = OWS ";" OWS "q=" qvalue 6037 <x:ref>word</x:ref> = <word, defined in [Part1], Section 3.2. 4>6037 <x:ref>word</x:ref> = <word, defined in [Part1], Section 3.2.6> 6038 6038 6039 6039 <x:ref>year</x:ref> = 4DIGIT
Note: See TracChangeset
for help on using the changeset viewer.