Changeset 1741
- Timestamp:
- 08/07/12 19:13:21 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1740 r1741 907 907 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 908 908 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 909 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>) and Via(<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 6.2</a>) header fields for both connections.909 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 6.2</a>) header fields for both connections. 910 910 </p> 911 911 <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 … … 985 985 <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default 986 986 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 987 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by 988 all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. 987 are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. 989 988 </p> 990 989 <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation 991 990 of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received 992 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connectionheader field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.991 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries. 993 992 </p> 994 993 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version … … 1215 1214 them. 1216 1215 </p> 1217 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connectionheader field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1216 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1218 1217 </p> 1219 1218 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1368 1367 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1369 1368 </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> 1370 <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message1371 framing is independent of method semantics, even if the method does not define any use for amessage body.1369 <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a 1370 message body. 1372 1371 </p> 1373 1372 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1374 status code (<a href="#status-code">Paragraph 3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1375 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.) 1373 status code (<a href="#status-code">Paragraph 3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.) 1376 1374 </p> 1377 1375 <div id="rfc.iref.t.4"></div> … … 1414 1412 <div id="rfc.iref.h.7"></div> 1415 1413 <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> 1416 <p id="rfc.section.3.3.2.p.1">When a message does not have a Transfer-Encoding header field and the payload body length can be determined prior to being 1417 transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses 1414 <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field and the payload body length can be determined prior to being transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses 1418 1415 other than <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, or would have been present had the request been an unconditional GET. The length is expressed as a decimal number of octets. 1419 1416 </p> … … 1447 1444 <li> 1448 1445 <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes 1449 the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encodingheader fields received in such a message.1446 the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message. 1450 1447 </p> 1451 1448 </li> 1452 1449 <li> 1453 <p>If a Transfer-Encodingheader 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-coding1450 <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-coding 1454 1451 indicates the data is complete. 1455 1452 </p> 1456 <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding,1457 the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header1458 field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot1459 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.1453 <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 1454 is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in 1455 a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably; 1456 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. 1460 1457 </p> 1461 <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding1462 o verrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of1463 security-related checks on message routing or content) and thus ought to be handled as anerror. 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-coding1458 <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 1459 or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an 1460 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 1464 1461 is decoded. 1465 1462 </p> 1466 1463 </li> 1467 1464 <li> 1468 <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing1469 f ield-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent,1465 <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message 1466 framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent, 1470 1467 it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. 1471 1468 </p> 1472 1469 </li> 1473 1470 <li> 1474 <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message body length1475 in octets. If the actual number of octets sent in the message is lessthan the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in1471 <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less 1472 than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in 1476 1473 the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection 1477 1474 and the connection has been closed by the server. … … 1491 1488 with HTTP/1.0. 1492 1489 </p> 1493 <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Lengthby responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.1494 </p> 1495 <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding,1496 since some existing servicesrespond 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 via1490 <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>. 1491 </p> 1492 <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 services 1493 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 via 1497 1494 a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire 1498 1495 request before processing. 1499 1496 </p> 1500 <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such1501 knowledge can be in the form ofspecific user configuration or by remembering the version of a prior received response.1497 <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 1498 specific user configuration or by remembering the version of a prior received response. 1502 1499 </p> 1503 1500 <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> … … 1509 1506 </p> 1510 1507 <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 1511 has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in 1512 octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length 1513 is terminated by closure of the connection, and thus is considered complete regardless of the number of message body octets 1514 received, provided that the header block was received intact. 1508 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 1509 that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered 1510 complete regardless of the number of message body octets received, provided that the header block was received intact. 1515 1511 </p> 1516 1512 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that … … 1551 1547 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1552 1548 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1553 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and in the Transfer-Encodingheader field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>).1549 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. HTTP/1.1 uses transfer-coding values in the <a href="#header.te" class="smpl">TE</a> header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and in the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>). 1554 1550 </p> 1555 1551 <div id="rfc.iref.c.7"></div> … … 1582 1578 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1583 1579 </p> 1584 <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1585 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.4</a>). 1580 <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The <a href="#header.trailer" class="smpl">Trailer</a> header field can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.4</a>). 1586 1581 </p> 1587 1582 <p id="rfc.section.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: 1588 1583 </p> 1589 1584 <ol> 1590 <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as 1591 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, 1592 1586 </li> 1593 1587 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable … … 1672 1666 TE: 1673 1667 TE: trailers, deflate;q=0.5 1674 </pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connectionheader field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) whenever TE is present in an HTTP/1.1 message.1668 </pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a <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>) whenever TE is present in an HTTP/1.1 message. 1675 1669 </p> 1676 1670 <p id="rfc.section.4.3.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> … … 1701 1695 </p> 1702 1696 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1703 <p id="rfc.section.4.3.1.p.1">Both transfer codings ( TErequest header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1697 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1704 1698 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1705 1699 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1726 1720 </p> 1727 1721 <ul> 1728 <li> Transfer-Encoding</li>1729 <li> Content-Length</li>1730 <li> Trailer</li>1722 <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li> 1723 <li><a href="#header.content-length" class="smpl">Content-Length</a></li> 1724 <li><a href="#header.trailer" class="smpl">Trailer</a></li> 1731 1725 </ul> 1732 1726 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> … … 1780 1774 <p id="rfc.section.5.3.p.3"><span id="rfc.iref.o.3"></span> The most common form of request-target is the origin-form. When making a request directly to an origin server, other than 1781 1775 a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send only the absolute path and query components of the target URI as the request-target. If the target URI's path component 1782 is empty, then the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A Hostheader field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 5.4</a>, containing the target URI's authority component (excluding any userinfo).1776 is empty, then the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A <a href="#header.host" class="smpl">Host</a> header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 5.4</a>, containing the target URI's authority component (excluding any userinfo). 1783 1777 </p> 1784 1778 </div> … … 1851 1845 <div id="rfc.iref.e.1"></div> 1852 1846 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1853 <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, Host, 1854 and connection context, in order to identify the intended target resource and properly service the request. The URI derived 1855 from this reconstruction process is referred to as the "effective request URI". 1847 <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request. 1848 The URI derived from this reconstruction process is referred to as the "effective request URI". 1856 1849 </p> 1857 1850 <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> … … 1863 1856 </p> 1864 1857 <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. 1865 Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the1866 Host field-value. Otherwise, the authority component is the concatenation of the default host name configured for the server,1867 a colon (":"), and the connection'sincoming TCP port number in decimal form.1858 Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise, 1859 the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's 1860 incoming TCP port number in decimal form. 1868 1861 </p> 1869 1862 <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component … … 1883 1876 </pre> <div id="rfc.figure.u.58"></div> 1884 1877 <p>has an effective request URI of</p> <pre class="text">https://www.example.org 1885 </pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Hostfield-value and instead replace it with a configured server name when constructing the effective request URI.1886 </p> 1887 <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a Hostheader field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess1878 </pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI. 1879 </p> 1880 <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess 1888 1881 the effective request URI's authority component. 1889 1882 </p> … … 1901 1894 except as noted above to replace an empty path with "/" or "*". 1902 1895 </p> 1903 <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the Connectionheader field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 6.1</a>.1896 <p id="rfc.section.5.6.p.5">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>. 1904 1897 </p> 1905 1898 <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a> <a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h3> … … 1915 1908 <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p> 1916 1909 <ul> 1917 <li>Connection</li> 1918 <li>Keep-Alive</li> 1919 <li>Proxy-Authenticate</li> 1920 <li>Proxy-Authorization</li> 1921 <li>TE</li> 1922 <li>Trailer</li> 1923 <li>Transfer-Encoding</li> 1924 <li>Upgrade</li> 1910 <li><a href="#header.connection" class="smpl">Connection</a></li> 1911 <li>Keep-Alive (<a href="http://tools.ietf.org/html/rfc2068#section-19.7.1.1">Section 19.7.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) 1912 </li> 1913 <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) 1914 </li> 1915 <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) 1916 </li> 1917 <li><a href="#header.te" class="smpl">TE</a></li> 1918 <li><a href="#header.trailer" class="smpl">Trailer</a></li> 1919 <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li> 1920 <li><a href="#header.upgrade" class="smpl">Upgrade</a></li> 1925 1921 </ul> 1926 1922 <p id="rfc.section.5.6.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> 1927 <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connectionheader field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>).1923 <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a <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>). 1928 1924 </p> 1929 1925 <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3> … … 2092 2088 </p> 2093 2089 <p id="rfc.section.6.3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 2094 takes place using the Connectionheader field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.2090 takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 2095 2091 </p> 2096 2092 <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> 2097 <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection 2098 option "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, 2099 it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2093 <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. If the server chooses to close the connection 2094 immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2100 2095 </p> 2101 2096 <p id="rfc.section.6.3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains 2102 a Connection header field with the connection option "close". In case the client does not want to maintain a connection for 2103 more than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2104 </p> 2105 <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the Connection header field, that request becomes the last 2106 one for the connection. 2097 a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". In case the client does not want to maintain a connection for more than that 2098 request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2099 </p> 2100 <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request becomes the last one for the connection. 2107 2101 </p> 2108 2102 <p id="rfc.section.6.3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2109 2103 </p> 2110 2104 <p id="rfc.section.6.3.2.1.p.5">Each persistent connection applies to only one transport link.</p> 2111 <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).2105 <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2112 2106 </p> 2113 2107 <p id="rfc.section.6.3.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. … … 2182 2176 </li> 2183 2177 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility 2184 with <a href="#RFC2068" id="rfc.xref.RFC2068. 4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"2178 with <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" 2185 2179 expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared 2186 2180 wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value. … … 2240 2234 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2241 2235 </p> 2242 <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connectionheader field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2236 <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2243 2237 </p> 2244 2238 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it … … 2331 2325 </div> 2332 2326 <p id="rfc.section.7.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field 2333 might conflict with the "close" connection option of the " Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>).2327 might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>). 2334 2328 </p> 2335 2329 <div id="rfc.table.u.1"> … … 2555 2549 </div> 2556 2550 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2> 2557 <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade 2558 header field. Each registered protocol-name is associated with contact information and an optional set of specifications that 2551 <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the <a href="#header.upgrade" class="smpl">Upgrade</a> header field. Each registered protocol name is associated with contact information and an optional set of specifications that 2559 2552 details how the connection will be processed after it has been upgraded. 2560 2553 </p> … … 2672 2665 </p> 2673 2666 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2674 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068. 5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari2667 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.6">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari 2675 2668 Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham. 2676 2669 See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions. … … 2712 2705 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 2713 2706 </h2> 2714 <table> 2707 <table> 2715 2708 <tr> 2716 2709 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2735 2728 <td class="reference"><b id="Part6">[Part6]</b></td> 2736 2729 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), July 2012. 2730 </td> 2731 </tr> 2732 <tr> 2733 <td class="reference"><b id="Part7">[Part7]</b></td> 2734 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), July 2012. 2737 2735 </td> 2738 2736 </tr> … … 2928 2926 </p> 2929 2927 <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts 2930 (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought2931 to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests2932 wh erein a buggy client failed to properly encode linear whitespace found in a URI reference and placed in the request-target.2928 (selection of resource by inspection of the <a href="#header.host" class="smpl">Host</a> header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that 2929 appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests wherein a buggy client failed to properly encode linear 2930 whitespace found in a URI reference and placed in the request-target. 2933 2931 </p> 2934 2932 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> 2935 2933 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 2936 2934 <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 2937 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Hostheader field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 5.3</a>) are among the most important changes defined by HTTP/1.1.2935 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the <a href="#header.host" class="smpl">Host</a> header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 5.3</a>) are among the most important changes defined by HTTP/1.1. 2938 2936 </p> 2939 2937 <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism 2940 for distinguishing the intended server of a request than the IP address to which that request was directed. The Host header 2941 field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers, 2938 for distinguishing the intended server of a request than the IP address to which that request was directed. The <a href="#header.host" class="smpl">Host</a> header field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers, 2942 2939 additional requirements were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing, 2943 2940 most HTTP-based services are dependent upon the Host header field for targeting requests. … … 2946 2943 <p id="rfc.section.A.1.2.p.1">In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the 2947 2944 response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections 2948 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2945 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2949 2946 </p> 2950 2947 <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly 2951 2948 negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0 2952 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand Connection, it will erroneously 2953 forward that header to the next inbound server, which would result in a hung connection. 2949 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header to the next inbound server, which would result in a hung connection. 2954 2950 </p> 2955 2951 <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this … … 2980 2976 <p id="rfc.section.A.2.p.6">Empty list elements in list productions have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a>) 2981 2977 </p> 2982 <p id="rfc.section.A.2.p.7">Require recipients to handle bogus Content-Lengthheader fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>)2978 <p id="rfc.section.A.2.p.7">Require recipients to handle bogus <a href="#header.content-length" class="smpl">Content-Length</a> header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) 2983 2979 </p> 2984 2980 <p id="rfc.section.A.2.p.8">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) … … 2997 2993 <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 6.1</a>) 2998 2994 </p> 2999 <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade"header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.5</a>)2995 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.5</a>) 3000 2996 </p> 3001 2997 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3772 3768 </ul> 3773 3769 </li> 3770 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">5.6.1</a>, <a href="#rfc.xref.Part7.2">5.6.1</a>, <a href="#Part7"><b>10.1</b></a><ul> 3771 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.1">5.6.1</a></li> 3772 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.2">5.6.1</a></li> 3773 </ul> 3774 </li> 3774 3775 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3775 3776 </ul> … … 3792 3793 </li> 3793 3794 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3794 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.4.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul> 3795 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li> 3795 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul> 3796 <li><em>Section 19.7.1.1</em> <a href="#rfc.xref.RFC2068.3">5.6.1</a></li> 3797 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li> 3796 3798 </ul> 3797 3799 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1740 r1741 36 36 <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 37 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 <!ENTITY header-proxy-authenticate "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 40 <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 41 <!ENTITY methods "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 503 505 that wishes to interoperate with third-party HTTP servers &MUST; 504 506 conform to HTTP user agent requirements on the gateway's inbound 505 connection and &MUST; implement the Connection506 (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)507 header fields for both connections.507 connection and &MUST; implement the <x:ref>Connection</x:ref> 508 (<xref target="header.connection"/>) and <x:ref>Via</x:ref> 509 (<xref target="header.via"/>) header fields for both connections. 508 510 </t> 509 511 <t><iref primary="true" item="tunnel"/> … … 662 664 behavior of a recipient in the absence of such a field can change. 663 665 Unless specified otherwise, header fields defined in HTTP/1.1 are 664 defined for all versions of HTTP/1.x. In particular, the Host and 665 Connection header fields ought to be implemented by all HTTP/1.x 666 implementations whether or not they advertise conformance with HTTP/1.1. 666 defined for all versions of HTTP/1.x. In particular, the <x:ref>Host</x:ref> 667 and <x:ref>Connection</x:ref> header fields ought to be implemented by all 668 HTTP/1.x implementations whether or not they advertise conformance with 669 HTTP/1.1. 667 670 </t> 668 671 <t> … … 674 677 the message's HTTP version. An unrecognized header field received 675 678 by a proxy &MUST; be forwarded downstream unless the header field's 676 field-name is listed in the message's Connectionheader field679 field-name is listed in the message's <x:ref>Connection</x:ref> header field 677 680 (see <xref target="header.connection"/>). 678 681 These requirements allow HTTP's functionality to be enhanced without … … 1162 1165 to the procedures in &cons-new-header-fields;. 1163 1166 Unrecognized header fields &MUST; be forwarded by a proxy unless the 1164 field-name is listed in the Connectionheader field1167 field-name is listed in the <x:ref>Connection</x:ref> header field 1165 1168 (<xref target="header.connection"/>) or the proxy is specifically 1166 1169 configured to block or otherwise transform such fields. … … 1474 1477 <t> 1475 1478 The presence of a message body in a request is signaled by a 1476 a Content-Length or Transfer-Encoding header field.1477 Request message framing is independent of method semantics,1479 a <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header 1480 field. Request message framing is independent of method semantics, 1478 1481 even if the method does not define any use for a message body. 1479 1482 </t> … … 1483 1486 status code (<xref target="status-code"/>). 1484 1487 Responses to the HEAD request method never include a message body 1485 because the associated response header fields (e.g., Transfer-Encoding,1486 Content-Length, etc.) only indicate what their values would have been1487 i f the request method had been GET.1488 <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of1489 having a message body.1488 because the associated response header fields (e.g., 1489 <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only 1490 indicate what their values would have been if the request method had been 1491 GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel 1492 mode instead of having a message body. 1490 1493 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and 1491 1494 <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body. … … 1587 1590 <x:anchor-alias value="Content-Length"/> 1588 1591 <t> 1589 When a message does not have a Transfer-Encoding header field and the1590 payload body length can be determined prior to being transferred, a1592 When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field 1593 and the payload body length can be determined prior to being transferred, a 1591 1594 Content-Length header field &SHOULD; be sent to indicate the length of the 1592 1595 payload body that is either present as the message body, for requests … … 1657 1660 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the 1658 1661 connection will become a tunnel immediately after the empty line that 1659 concludes the header fields. A client &MUST; ignore any Content-Length 1660 or Transfer-Encoding header fields received in such a message. 1662 concludes the header fields. A client &MUST; ignore any 1663 <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header 1664 fields received in such a message. 1661 1665 </t></x:lt> 1662 1666 <x:lt><t> 1663 If a Transfer-Encodingheader field is present1667 If a <x:ref>Transfer-Encoding</x:ref> header field is present 1664 1668 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>) 1665 1669 is the final encoding, the message body length is determined by reading … … 1668 1672 </t> 1669 1673 <t> 1670 If a Transfer-Encoding header field is present in a response and the1671 "chunked" transfer-coding is not the final encoding, the message body1672 length is determined by reading the connection until it is closed by1673 the server.1674 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a 1675 response and the "chunked" transfer-coding is not the final encoding, the 1676 message body length is determined by reading the connection until it is 1677 closed by the server. 1674 1678 If a Transfer-Encoding header field is present in a request and the 1675 1679 "chunked" transfer-coding is not the final encoding, the message body … … 1678 1682 </t> 1679 1683 <t> 1680 If a message is received with both a Transfer-Encoding header field1681 and a Content-Length header field, the Transfer-Encoding overrides1682 the Content-Length.1684 If a message is received with both a <x:ref>Transfer-Encoding</x:ref> 1685 and a <x:ref>Content-Length</x:ref> header field, the 1686 Transfer-Encoding overrides the Content-Length. 1683 1687 Such a message might indicate an attempt to perform request or response 1684 1688 smuggling (bypass of security-related checks on message routing or content) … … 1688 1692 </t></x:lt> 1689 1693 <x:lt><t> 1690 If a message is received without Transfer-Encoding and with either1691 multiple Content-Length header fields having differing field-values or1692 a single Content-Length header field having an invalid value, then the1693 message framing is invalid and &MUST; be treated as an error to1694 prevent request or response smuggling.1694 If a message is received without <x:ref>Transfer-Encoding</x:ref> and with 1695 either multiple <x:ref>Content-Length</x:ref> header fields having 1696 differing field-values or a single Content-Length header field having an 1697 invalid value, then the message framing is invalid and &MUST; be treated 1698 as an error to prevent request or response smuggling. 1695 1699 If this is a request message, the server &MUST; respond with 1696 1700 a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. … … 1702 1706 </t></x:lt> 1703 1707 <x:lt><t> 1704 If a valid Content-Length header field1705 is present without Transfer-Encoding, its decimal value defines the1708 If a valid <x:ref>Content-Length</x:ref> header field is present without 1709 <x:ref>Transfer-Encoding</x:ref>, its decimal value defines the 1706 1710 message body length in octets. If the actual number of octets sent in 1707 1711 the message is less than the indicated Content-Length, the recipient … … 1736 1740 <t> 1737 1741 A server &MAY; reject a request that contains a message body but 1738 not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>. 1742 not a <x:ref>Content-Length</x:ref> by responding with 1743 <x:ref>411 (Length Required)</x:ref>. 1739 1744 </t> 1740 1745 <t> 1741 1746 Unless a transfer-coding other than "chunked" has been applied, 1742 1747 a client that sends a request containing a message body &SHOULD; 1743 use a valid Content-Length header field if the message body length1744 is known in advance, rather than the "chunked" encoding, since some1748 use a valid <x:ref>Content-Length</x:ref> header field if the message body 1749 length is known in advance, rather than the "chunked" encoding, since some 1745 1750 existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref> 1746 1751 status code even though they understand the chunked encoding. This … … 1751 1756 <t> 1752 1757 A client that sends a request containing a message body &MUST; include a 1753 valid Content-Length header field if it does not know the server will1754 handle HTTP/1.1 (or later) requests; such knowledge can be in the form1755 of specific user configuration or by remembering the version of a prior1756 received response.1758 valid <x:ref>Content-Length</x:ref> header field if it does not know the 1759 server will handle HTTP/1.1 (or later) requests; such knowledge can be in 1760 the form of specific user configuration or by remembering the version of a 1761 prior received response. 1757 1762 </t> 1758 1763 </section> … … 1777 1782 A message body that uses the chunked transfer encoding is 1778 1783 incomplete if the zero-sized chunk that terminates the encoding has not 1779 been received. A message that uses a valid Content-Length is incomplete1780 i f the size of the message body received (in octets) is less than the1781 value given by Content-Length. A response that has neither chunked1784 been received. A message that uses a valid <x:ref>Content-Length</x:ref> is 1785 incomplete if the size of the message body received (in octets) is less than 1786 the value given by Content-Length. A response that has neither chunked 1782 1787 transfer encoding nor Content-Length is terminated by closure of the 1783 1788 connection, and thus is considered complete regardless of the number of … … 1866 1871 The HTTP Transfer Coding registry is defined in 1867 1872 <xref target="transfer.coding.registry"/>. 1868 HTTP/1.1 uses transfer-coding values in the TEheader field1869 (<xref target="header.te"/>) and in the Transfer-Encoding header field1870 (<xref target="header.transfer-encoding"/>).1873 HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field 1874 (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref> 1875 header field (<xref target="header.transfer-encoding"/>). 1871 1876 </t> 1872 1877 … … 1921 1926 <t> 1922 1927 The trailer allows the sender to include additional HTTP header 1923 fields at the end of the message. The Trailer header field can be1924 used to indicate which header fields are included in a trailer (see1928 fields at the end of the message. The <x:ref>Trailer</x:ref> header field 1929 can be used to indicate which header fields are included in a trailer (see 1925 1930 <xref target="header.trailer"/>). 1926 1931 </t> … … 1930 1935 true: 1931 1936 <list style="numbers"> 1932 <t>the request included a TE header field that indicates "trailers" is1933 acceptable in the transfer-coding of the response, as described in1934 <xref target="header.te"/>; or,</t>1937 <t>the request included a <x:ref>TE</x:ref> header field that indicates 1938 "trailers" is acceptable in the transfer-coding of the response, as 1939 described in <xref target="header.te"/>; or,</t> 1935 1940 1936 1941 <t>the trailer fields consist entirely of optional metadata, and the … … 2076 2081 <t> 2077 2082 The TE header field only applies to the immediate connection. 2078 Therefore, the keyword &MUST; be supplied within a Connection header 2079 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. 2083 Therefore, the keyword &MUST; be supplied within a <x:ref>Connection</x:ref> 2084 header field (<xref target="header.connection"/>) whenever TE is present in 2085 an HTTP/1.1 message. 2080 2086 </t> 2081 2087 <t> … … 2120 2126 <x:anchor-alias value="qvalue"/> 2121 2127 <t> 2122 Both transfer codings ( TE request header field, <xref target="header.te"/>)2123 and content negotiation (&content.negotiation;) use short "floating point"2124 numbers to indicate the relative importance ("weight") of various2125 negotiable parameters. A weight is normalized to a real number in2126 the range 0 through 1, where 0 is the minimum and 1 the maximum2127 value. If a parameter has a quality value of 0, then content with2128 Both transfer codings (<x:ref>TE</x:ref> request header field, 2129 <xref target="header.te"/>) and content negotiation (&content.negotiation;) 2130 use short "floating point" numbers to indicate the relative importance 2131 ("weight") of various negotiable parameters. A weight is normalized to a 2132 real number in the range 0 through 1, where 0 is the minimum and 1 the 2133 maximum value. If a parameter has a quality value of 0, then content with 2128 2134 this parameter is "not acceptable" for the client. HTTP/1.1 2129 2135 applications &MUST-NOT; generate more than three digits after the … … 2171 2177 include the following header fields: 2172 2178 <list style="symbols"> 2173 <t> Transfer-Encoding</t>2174 <t> Content-Length</t>2175 <t> Trailer</t>2179 <t><x:ref>Transfer-Encoding</x:ref></t> 2180 <t><x:ref>Content-Length</x:ref></t> 2181 <t><x:ref>Trailer</x:ref></t> 2176 2182 </list> 2177 2183 </t> … … 2273 2279 If the target URI's path component is empty, then the client &MUST; send 2274 2280 "/" as the path within the origin-form of request-target. 2275 A Hostheader field is also sent, as defined in2281 A <x:ref>Host</x:ref> header field is also sent, as defined in 2276 2282 <xref target="header.host"/>, containing the target URI's 2277 2283 authority component (excluding any userinfo). … … 2428 2434 A server that receives an HTTP request message &MUST; reconstruct 2429 2435 the user agent's original target URI, based on the pieces of information 2430 learned from the request-target, Host, and connection context, in order2431 to identify the intended target resource and properly service the request.2432 The URI derived from this reconstruction process is referred to as the2433 "effective request URI".2436 learned from the request-target, <x:ref>Host</x:ref> header field, and 2437 connection context, in order to identify the intended target resource and 2438 properly service the request. The URI derived from this reconstruction 2439 process is referred to as the "effective request URI". 2434 2440 </t> 2435 2441 <t> … … 2449 2455 If the request-target is in authority-form, then the effective 2450 2456 request URI's authority component is the same as the request-target. 2451 Otherwise, if a Host header field is supplied with a non-empty field-value,2452 then the authority component is the same as the Host field-value.2453 Otherwise, the authority component is the concatenation of the default2454 host name configured for the server, a colon (":"), and the connection's2455 incoming TCP port number in decimal form.2457 Otherwise, if a <x:ref>Host</x:ref> header field is supplied with a 2458 non-empty field-value, then the authority component is the same as the 2459 Host field-value. Otherwise, the authority component is the concatenation of 2460 the default host name configured for the server, a colon (":"), and the 2461 connection's incoming TCP port number in decimal form. 2456 2462 </t> 2457 2463 <t> … … 2503 2509 <t> 2504 2510 An origin server that does not allow resources to differ by requested 2505 host &MAY; ignore the Host field-value and instead replace it with a2506 configured server name when constructing the effective request URI.2507 </t> 2508 <t> 2509 Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;2510 attempt to use heuristics (e.g., examination of the URI path for2511 host &MAY; ignore the <x:ref>Host</x:ref> field-value and instead replace it 2512 with a configured server name when constructing the effective request URI. 2513 </t> 2514 <t> 2515 Recipients of an HTTP/1.0 request that lacks a <x:ref>Host</x:ref> header 2516 field &MAY; attempt to use heuristics (e.g., examination of the URI path for 2511 2517 something unique to a particular host) in order to guess the 2512 2518 effective request URI's authority component. … … 2542 2548 <t> 2543 2549 Intermediaries that forward a message &MUST; implement the 2544 Connection header field as specified in <xref target="header.connection"/>. 2550 <x:ref>Connection</x:ref> header field as specified in 2551 <xref target="header.connection"/>. 2545 2552 </t> 2546 2553 … … 2569 2576 The following HTTP/1.1 header fields are hop-by-hop header fields: 2570 2577 <list style="symbols"> 2571 <t> Connection</t>2572 <t>Keep-Alive </t>2573 <t> Proxy-Authenticate</t>2574 <t> Proxy-Authorization</t>2575 <t> TE</t>2576 <t> Trailer</t>2577 <t> Transfer-Encoding</t>2578 <t> Upgrade</t>2578 <t><x:ref>Connection</x:ref></t> 2579 <t>Keep-Alive (<xref target="RFC2068" x:fmt="of" x:sec="19.7.1.1"/>)</t> 2580 <t><x:ref>Proxy-Authenticate</x:ref> (&header-proxy-authenticate;)</t> 2581 <t><x:ref>Proxy-Authorization</x:ref> (&header-proxy-authorization;)</t> 2582 <t><x:ref>TE</x:ref></t> 2583 <t><x:ref>Trailer</x:ref></t> 2584 <t><x:ref>Transfer-Encoding</x:ref></t> 2585 <t><x:ref>Upgrade</x:ref></t> 2579 2586 </list> 2580 2587 </t> … … 2583 2590 </t> 2584 2591 <t> 2585 Other hop-by-hop header fields &MUST; be listed in a Connection header field2586 (<xref target="header.connection"/>).2592 Other hop-by-hop header fields &MUST; be listed in a 2593 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>). 2587 2594 </t> 2588 2595 </section> … … 2930 2937 Persistent connections provide a mechanism by which a client and a 2931 2938 server can signal the close of a TCP connection. This signaling takes 2932 place using the Connection header field (<xref target="header.connection"/>). Once a close 2933 has been signaled, the client &MUST-NOT; send any more requests on that 2939 place using the <x:ref>Connection</x:ref> header field 2940 (<xref target="header.connection"/>). Once a close has been signaled, the 2941 client &MUST-NOT; send any more requests on that 2934 2942 connection. 2935 2943 </t> … … 2938 2946 <t> 2939 2947 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2940 maintain a persistent connection unless a Connection header field including2941 the connection option "close" was sent in the request. If the server2942 chooses to close the connection immediately after sending the2948 maintain a persistent connection unless a <x:ref>Connection</x:ref> header 2949 field including the connection option "close" was sent in the request. If 2950 the server chooses to close the connection immediately after sending the 2943 2951 response, it &SHOULD; send a Connection header field including the 2944 2952 connection option "close". … … 2947 2955 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2948 2956 decide to keep it open based on whether the response from a server 2949 contains a Connection header field with the connection option "close". In case2950 the client does not want to maintain a connection for more than that2951 request, it &SHOULD; send a Connection header field including the2957 contains a <x:ref>Connection</x:ref> header field with the connection option 2958 "close". In case the client does not want to maintain a connection for more 2959 than that request, it &SHOULD; send a Connection header field including the 2952 2960 connection option "close". 2953 2961 </t> 2954 2962 <t> 2955 2963 If either the client or the server sends the "close" option in the 2956 Connection header field, that request becomes the last one for the2957 connection.2964 <x:ref>Connection</x:ref> header field, that request becomes the last one 2965 for the connection. 2958 2966 </t> 2959 2967 <t> … … 3273 3281 <t> 3274 3282 The Upgrade header field only applies to the immediate connection. 3275 Therefore, the upgrade keyword &MUST; be supplied within a Connection3276 header field (<xref target="header.connection"/>) whenever Upgrade is present in an3277 HTTP/1.1 message.3283 Therefore, the upgrade keyword &MUST; be supplied within a 3284 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>) 3285 whenever Upgrade is present in an HTTP/1.1 message. 3278 3286 </t> 3279 3287 <t> … … 3376 3384 Furthermore, the header field-name "Close" shall be registered as 3377 3385 "reserved", since using that name as an HTTP header field might 3378 conflict with the "close" connection option of the " Connection"3386 conflict with the "close" connection option of the "<x:ref>Connection</x:ref>" 3379 3387 header field (<xref target="header.connection"/>). 3380 3388 </t> … … 3639 3647 <t> 3640 3648 The HTTP Upgrade Token Registry defines the name space for protocol-name 3641 tokens used to identify protocols in the Upgrade header field.3642 Each registered protocol-name is associated with contact information and3643 an optional set of specifications that details how the connection3649 tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header 3650 field. Each registered protocol name is associated with contact information 3651 and an optional set of specifications that details how the connection 3644 3652 will be processed after it has been upgraded. 3645 3653 </t> … … 4222 4230 </reference> 4223 4231 4232 <reference anchor="Part7"> 4233 <front> 4234 <title>HTTP/1.1, part 7: Authentication</title> 4235 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4236 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> 4237 <address><email>fielding@gbiv.com</email></address> 4238 </author> 4239 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> 4240 <organization abbrev="W3C">World Wide Web Consortium</organization> 4241 <address><email>ylafon@w3.org</email></address> 4242 </author> 4243 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> 4244 <organization abbrev="greenbytes">greenbytes GmbH</organization> 4245 <address><email>julian.reschke@greenbytes.de</email></address> 4246 </author> 4247 <date month="&ID-MONTH;" year="&ID-YEAR;"/> 4248 </front> 4249 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/> 4250 <x:source href="p7-auth.xml" basename="p7-auth"> 4251 <x:defines>Proxy-Authenticate</x:defines> 4252 <x:defines>Proxy-Authorization</x:defines> 4253 </x:source> 4254 </reference> 4255 4224 4256 <reference anchor="RFC5234"> 4225 4257 <front> … … 4833 4865 Since HTTP/0.9 did not support header fields in a request, 4834 4866 there is no mechanism for it to support name-based virtual 4835 hosts (selection of resource by inspection of the Hostheader4867 hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header 4836 4868 field). Any server that implements name-based virtual hosts 4837 4869 ought to disable support for HTTP/0.9. Most requests that … … 4850 4882 <section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4851 4883 <t> 4852 The requirements that clients and servers support the Host header4853 field (<xref target="header.host"/>), report an error if it is4884 The requirements that clients and servers support the <x:ref>Host</x:ref> 4885 header field (<xref target="header.host"/>), report an error if it is 4854 4886 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4855 4887 are among the most important changes defined by HTTP/1.1. … … 4859 4891 addresses and servers; there was no other established mechanism for 4860 4892 distinguishing the intended server of a request than the IP address 4861 to which that request was directed. The Hostheader field was4893 to which that request was directed. The <x:ref>Host</x:ref> header field was 4862 4894 introduced during the development of HTTP/1.1 and, though it was 4863 4895 quickly implemented by most HTTP/1.0 browsers, additional requirements … … 4881 4913 with a "Connection: keep-alive" request header field. However, some 4882 4914 experimental implementations of HTTP/1.0 persistent connections are faulty; 4883 for example, if a HTTP/1.0 proxy server doesn't understand Connection, it4884 will erroneously forward that header to the next inbound server, which4885 would result in a hung connection.4915 for example, if a HTTP/1.0 proxy server doesn't understand 4916 <x:ref>Connection</x:ref>, it will erroneously forward that header to the 4917 next inbound server, which would result in a hung connection. 4886 4918 </t> 4887 4919 <t> … … 4942 4974 </t> 4943 4975 <t> 4944 Require recipients to handle bogus Content-Length header fields as errors. 4976 Require recipients to handle bogus <x:ref>Content-Length</x:ref> header 4977 fields as errors. 4945 4978 (<xref target="message.body"/>) 4946 4979 </t> … … 4980 5013 </t> 4981 5014 <t> 4982 Define the semantics of the "Upgrade" header field in responses other than4983 101 (this was incorporated from <xref target="RFC2817"/>).5015 Define the semantics of the <x:ref>Upgrade</x:ref> header field in responses 5016 other than 101 (this was incorporated from <xref target="RFC2817"/>). 4984 5017 (<xref target="header.upgrade"/>) 4985 5018 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1740 r1741 967 967 </p> 968 968 <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 969 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Lengthfield with a field-value of "0".969 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0". 970 970 </p> 971 971 <p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. … … 1114 1114 </p> 1115 1115 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1116 or diagnostic information. The value of the Viaheader field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 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 forwarding1116 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 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 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 1117 1117 messages in an infinite loop. 1118 1118 </p> … … 1133 1133 </pre><p id="rfc.section.2.3.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has 1134 1134 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1135 after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1136 </p> 1137 <p id="rfc.section.2.3.8.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1135 after the blank line that concludes the successful response's header block. 1136 </p> 1137 <p id="rfc.section.2.3.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1138 </p> 1139 <p id="rfc.section.2.3.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1138 1140 governed by HTTP. 1139 1141 </p> 1140 <p id="rfc.section.2.3.8.p. 6">Proxy authentication might be used to establish the authority to create a tunnel:</p>1142 <p id="rfc.section.2.3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1141 1143 <div id="rfc.figure.u.5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1142 1144 Host: server.example.com:80 1143 1145 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1144 1146 1145 </pre><p id="rfc.section.2.3.8.p. 8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations1147 </pre><p id="rfc.section.2.3.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 1146 1148 to reject the request. 1147 1149 </p> 1148 <p id="rfc.section.2.3.8.p. 9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded1150 <p id="rfc.section.2.3.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1149 1151 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1150 1152 </p> 1151 <p id="rfc.section.2.3.8.p.1 0">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,1153 <p id="rfc.section.2.3.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, 1152 1154 the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority. 1153 1155 </p> 1154 <p id="rfc.section.2.3.8.p.1 1">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to1156 <p id="rfc.section.2.3.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1155 1157 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1156 1158 peer undelivered, that data will be discarded. 1157 1159 </p> 1158 <p id="rfc.section.2.3.8.p.1 2">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.1160 <p id="rfc.section.2.3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1159 1161 </p> 1160 1162 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> … … 1207 1209 </li> 1208 1210 <li> 1209 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the headeris to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1211 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1210 1212 </p> 1211 1213 </li> … … 1673 1675 <div id="rfc.iref.s.5"></div> 1674 1676 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1675 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrademessage header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1677 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1676 1678 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1677 1679 </p> … … 1987 1989 <div id="rfc.iref.s.31"></div> 1988 1990 <h3 id="rfc.section.4.6.10"><a href="#rfc.section.4.6.10">4.6.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 1989 <p id="rfc.section.4.6.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request1991 <p id="rfc.section.4.6.10.p.1">The server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request 1990 1992 message. 1991 1993 </p> … … 2022 2024 <div id="rfc.iref.s.36"></div> 2023 2025 <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2024 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgradeheader field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2026 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2025 2027 </p> 2026 2028 <div id="rfc.figure.u.7"></div> … … 2349 2351 </div> 2350 2352 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 2351 <p id="rfc.section.6.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure 2352 safe and proper transfer of the message. 2353 <p id="rfc.section.6.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 2353 2354 </p> 2354 2355 <div id="rfc.iref.r.1"></div> … … 2369 2370 in an HTTP message, it is referred to as the payload of the message. 2370 2371 </p> 2371 <p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 2372 to ensure safe and proper transfer of the message. 2372 <p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message. 2373 2373 </p> 2374 2374 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> … … 3052 3052 </pre><p id="rfc.section.9.17.p.4">Example:</p> 3053 3053 <div id="rfc.figure.u.60"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 3054 </pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Viafield (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).3054 </pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <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 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 3055 3055 </p> 3056 3056 <div class="note" id="rfc.section.9.17.p.7"> … … 3606 3606 </p> 3607 3607 <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, 3608 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Viafields generated behind the firewall.3608 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall. 3609 3609 </p> 3610 3610 <p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can … … 3925 3925 </p> 3926 3926 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 3927 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encodingheader field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.3927 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 3928 3928 </p> 3929 3929 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1740 r1741 551 551 future extensions to HTTP. Content negotiation &MAY; be used to select 552 552 the appropriate response format. If no response body is included, the 553 response &MUST; include a Content-Length field with a field-value of554 "0".553 response &MUST; include a <x:ref>Content-Length</x:ref> field with a 554 field-value of "0". 555 555 </t> 556 556 <t> … … 881 881 TRACE allows the client to see what is being received at the other 882 882 end of the request chain and use that data for testing or diagnostic 883 information. The value of the Via header field (&header-via;) is of884 particular interest, since it acts as a trace of the request chain.883 information. The value of the <x:ref>Via</x:ref> header field (&header-via;) 884 is of particular interest, since it acts as a trace of the request chain. 885 885 Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to 886 886 limit the length of the request chain, which is useful for testing a chain of … … 921 921 The tunneled data from the server begins immediately after the blank line 922 922 that concludes the successful response's header block. 923 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length 924 header fields in a successful response. 923 </t> 924 <t> 925 A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or 926 <x:ref>Content-Length</x:ref> header fields in a successful response. 925 927 A client &MUST; ignore any Content-Length or Transfer-Encoding header 926 928 fields received in a successful response. … … 1056 1058 responses or requests, in all messages, only on responses to a particular 1057 1059 request method.</t></x:lt> 1058 <x:lt><t>Whether it is appropriate to list the field-name in the Connection header 1059 (i.e., if the header is to be hop-by-hop, see &header-connection;).</t></x:lt> 1060 <x:lt><t>Whether it is appropriate to list the field-name in the 1061 <x:ref>Connection</x:ref> header field (i.e., if the header field is to 1062 be hop-by-hop, see &header-connection;).</t></x:lt> 1060 1063 <x:lt><t>Under what conditions intermediaries are allowed to modify the header 1061 1064 field's value, insert or delete it.</t></x:lt> … … 1347 1350 <x:anchor-alias value="101 (Switching Protocols)"/> 1348 1351 <t> 1349 The server understands and is willing to comply with the client's 1350 request, via the Upgrade message header field (&header-upgrade;), for a1351 change in the application protocol being used on this connection. The1352 server will switch protocols to those defined by the response's 1353 Upgrade header field immediately after the empty line which1354 terminates the 101response.1352 The server understands and is willing to comply with the client's request, 1353 via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for 1354 a change in the application protocol being used on this connection. The 1355 server will switch protocols to those defined by the response's Upgrade 1356 header field immediately after the empty line which terminates the 101 1357 response. 1355 1358 </t> 1356 1359 <t> … … 1984 1987 <x:anchor-alias value="411 (Length Required)"/> 1985 1988 <t> 1986 The server refuses to accept the request without a defined Content-Length.1987 The client &MAY; repeat the request if it adds a valid1988 Content-Length header field containing the length of the message body1989 in the request message.1989 The server refuses to accept the request without a defined 1990 <x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it 1991 adds a valid Content-Length header field containing the length of the 1992 message body in the request message. 1990 1993 </t> 1991 1994 </section> … … 2053 2056 <t> 2054 2057 The request can not be completed without a prior protocol upgrade. This 2055 response &MUST; include an Upgrade header field (&header-upgrade;)2056 specifying the required protocols.2058 response &MUST; include an <x:ref>Upgrade</x:ref> header field 2059 (&header-upgrade;) specifying the required protocols. 2057 2060 </t> 2058 2061 <figure> … … 2661 2664 A payload body is only present in a message when a message body is 2662 2665 present, as described in &message-body;. The payload body is obtained 2663 from the message body by decoding any Transfer-Encoding that might2664 have been applied to ensure safe and proper transfer of the message.2666 from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that 2667 might have been applied to ensure safe and proper transfer of the message. 2665 2668 </t> 2666 2669 </section> … … 2701 2704 A representation body is only present in a message when a message body is 2702 2705 present, as described in &message-body;. The representation body is obtained 2703 from the message body by decoding any Transfer-Encoding that might2704 have been applied to ensure safe and proper transfer of the message.2706 from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that 2707 might have been applied to ensure safe and proper transfer of the message. 2705 2708 </t> 2706 2709 … … 3938 3941 </artwork></figure> 3939 3942 <t> 3940 If the response is being forwarded through a proxy, the proxy 3941 application &MUST-NOT; modify the Serverheader field. Instead, it3942 &MUST; include a Viafield (as described in &header-via;).3943 If the response is being forwarded through a proxy, the proxy application 3944 &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it 3945 &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;). 3943 3946 </t> 3944 3947 <x:note> … … 4478 4481 take special precautions regarding the transfer of header information 4479 4482 that identifies the hosts behind the firewall. In particular, they 4480 &SHOULD; remove, or replace with sanitized versions, any Via fields4481 generated behind the firewall.4483 &SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref> 4484 fields generated behind the firewall. 4482 4485 </t> 4483 4486 <t> … … 4645 4648 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> 4646 4649 <x:source href="p1-messaging.xml" basename="p1-messaging"> 4650 <x:defines>Connection</x:defines> 4647 4651 <x:defines>Content-Length</x:defines> 4648 4652 <x:defines>Transfer-Encoding</x:defines> 4653 <x:defines>Upgrade</x:defines> 4649 4654 <x:defines>Via</x:defines> 4650 4655 </x:source> … … 5443 5448 <section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding"> 5444 5449 <t> 5445 HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).5446 Proxies/gateways &MUST; remove any transfer-coding prior to5447 forwarding a message via a MIME-compliant protocol.5450 HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field 5451 (&header-transfer-encoding;). Proxies/gateways &MUST; remove any 5452 transfer-coding prior to forwarding a message via a MIME-compliant protocol. 5448 5453 </t> 5449 5454 </section> -
draft-ietf-httpbis/latest/p5-range.html
r1740 r1741 771 771 </h2> 772 772 <p id="rfc.section.4.1.p.1">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to 773 a request for a set of ranges that overlap without any holes), this content is transmitted with a <a href="#header.content-range" class="smpl">Content-Range</a> header field, and a Content-Lengthheader field showing the number of bytes actually transferred. For example,773 a request for a set of ranges that overlap without any holes), this content is transmitted with a <a href="#header.content-range" class="smpl">Content-Range</a> header field, and a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field showing the number of bytes actually transferred. For example, 774 774 </p> 775 775 <div id="rfc.figure.u.5"></div><pre class="text">HTTP/1.1 206 Partial Content … … 807 807 </p> 808 808 <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected 809 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a Content-Lengthheader field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range809 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range 810 810 of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple <a href="#status.206" class="smpl">206</a> responses with one continuous range each. 811 811 </p> -
draft-ietf-httpbis/latest/p5-range.xml
r1740 r1741 403 403 for a set of ranges that overlap without any holes), this content is 404 404 transmitted with a <x:ref>Content-Range</x:ref> header field, and a 405 Content-Length header field showing the number of bytes actually transferred.406 For example,405 <x:ref>Content-Length</x:ref> header field showing the number of bytes 406 actually transferred. For example, 407 407 </t> 408 408 <figure><artwork type="message/http; msgtype="response"" x:indent-with=" "> … … 481 481 content ranges in the new response and each of the selected responses. 482 482 If the union consists of the entire range of the representation, then the 483 combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> response 484 with a Content-Length header field that reflects the complete length. 485 Otherwise, the combined response(s) &MUST; include a <x:ref>Content-Range</x:ref> 486 header field describing the included range(s) and be recorded as 487 incomplete. If the union consists of a discontinuous range of the 488 representation, then the client &MAY; store it as either a multipart range 489 response or as multiple <x:ref>206</x:ref> responses with one continuous range each. 483 combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> 484 response with a <x:ref>Content-Length</x:ref> header field that reflects the 485 complete length. Otherwise, the combined response(s) &MUST; include a 486 <x:ref>Content-Range</x:ref> header field describing the included range(s) 487 and be recorded as incomplete. If the union consists of a discontinuous 488 range of the representation, then the client &MAY; store it as either a 489 multipart range response or as multiple <x:ref>206</x:ref> responses with 490 one continuous range each. 490 491 </t> 491 492 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r1740 r1741 1028 1028 <p>These <em class="bcp14">SHOULD</em> be combined as 1029 1029 </p> <pre class="text"> corrected_initial_age = max(apparent_age, corrected_age_value); 1030 </pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the Viaheader field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.1030 </pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age. 1031 1031 </p> 1032 1032 <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response … … 1120 1120 a body. This property of HEAD responses is used to both invalidate and update cached GET responses. 1121 1121 </p> 1122 <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>) for a HEAD request, and the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.1123 </p> 1124 <p id="rfc.section.2.5.p.3">If the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:1122 <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1123 </p> 1124 <p id="rfc.section.2.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 1125 1125 </p> 1126 1126 <ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r1740 r1741 808 808 <t> 809 809 unless the cache is confident in the value of the <x:ref>Age</x:ref> header 810 field (e.g., because there are no HTTP/1.0 hops in the Via header field), in811 which case the corrected_age_value &MAY; be used as the810 field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref> 811 header field), in which case the corrected_age_value &MAY; be used as the 812 812 corrected_initial_age.</t> 813 813 <t> … … 991 991 If one or more stored GET responses can be selected (as per <xref 992 992 target="caching.negotiated.responses"/>) for a HEAD request, and the 993 Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of 994 a HEAD response differs from that in a selected GET response, the cache 995 &MUST; consider that selected response to be stale. 996 </t> 997 <t> 998 If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref> 999 values of a HEAD response (when present) are the same as that in a selected 1000 GET response (as per <xref target="caching.negotiated.responses"/>), the 1001 cache &SHOULD; update the remaining headers in the stored response using the 1002 following rules: 993 <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or 994 <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a 995 selected GET response, the cache &MUST; consider that selected response to 996 be stale. 997 </t> 998 <t> 999 If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and 1000 <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are 1001 the same as that in a selected GET response (as per 1002 <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update 1003 the remaining headers in the stored response using the following rules: 1003 1004 <list style="symbols"> 1004 1005 <t>delete any <x:ref>Warning</x:ref> header fields in the stored response … … 2280 2281 </front> 2281 2282 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" /> 2282 <x:source basename="p1-messaging" href="p1-messaging.xml" /> 2283 <x:source basename="p1-messaging" href="p1-messaging.xml"> 2284 <x:defines>Content-Length</x:defines> 2285 <x:defines>Via</x:defines> 2286 </x:source> 2283 2287 </reference> 2284 2288
Note: See TracChangeset
for help on using the changeset viewer.