Ignore:
Timestamp:
Jul 8, 2012, 12:13:21 PM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions (P1)

Location:
draft-ietf-httpbis/latest
Files:
8 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1740 r1741  
    907907         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    908908         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&nbsp;6.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;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&nbsp;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&nbsp;6.2</a>) header fields for both connections.
    910910      </p>
    911911      <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
     
    985985      <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
    986986         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.
    989988      </p>
    990989      <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
    991990         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 Connection header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;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&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
    993992      </p>
    994993      <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
     
    12151214         them.
    12161215      </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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;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&nbsp;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.
    12181217      </p>
    12191218      <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"
     
    13681367      <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
    13691368</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 message
    1371          framing is independent of method semantics, even if the method does not define any use for a message 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.
    13721371      </p>
    13731372      <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&nbsp;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&nbsp;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>.)
    13761374      </p>
    13771375      <div id="rfc.iref.t.4"></div>
     
    14141412      <div id="rfc.iref.h.7"></div>
    14151413      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<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
    14181415         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.
    14191416      </p>
     
    14471444         <li>
    14481445            <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-Encoding header 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.
    14501447            </p>
    14511448         </li>
    14521449         <li>
    1453             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
     1450            <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&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
    14541451               indicates the data is complete.
    14551452            </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 header
    1458                field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot
    1459                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.
    14601457            </p>
    1461             <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
    1462                overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of
    1463                security-related checks on message routing or content) and thus ought to be handled as an 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
     1458            <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
    14641461               is decoded.
    14651462            </p>
    14661463         </li>
    14671464         <li>
    1468             <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing
    1469                field-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,
    14701467               it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
    14711468            </p>
    14721469         </li>
    14731470         <li>
    1474             <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message body length
    1475                in octets. If the actual number of octets sent in the message is less 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
     1471            <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
    14761473               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
    14771474               and the connection has been closed by the server.
     
    14911488         with HTTP/1.0.
    14921489      </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-Length by 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 services respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
     1490      <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
    14971494         a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire
    14981495         request before processing.
    14991496      </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; such
    1501          knowledge can be in the form of specific 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.
    15021499      </p>
    15031500      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2>
     
    15091506      </p>
    15101507      <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.
    15151511      </p>
    15161512      <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
     
    15511547  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    15521548  <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&nbsp;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&nbsp;4.3</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;3.3.1</a>).
    15541550      </p>
    15551551      <div id="rfc.iref.c.7"></div>
     
    15821578         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    15831579      </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&nbsp;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&nbsp;4.4</a>).
    15861581      </p>
    15871582      <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:
    15881583      </p>
    15891584      <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&nbsp;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&nbsp;4.3</a>; or,
    15921586         </li>
    15931587         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
     
    16721666  TE:
    16731667  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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;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&nbsp;6.1</a>) whenever TE is present in an HTTP/1.1 message.
    16751669      </p>
    16761670      <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>
     
    17011695      </p>
    17021696      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1703       <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;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
     1697      <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&nbsp;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
    17041698         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
    17051699         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.
     
    17261720      </p>
    17271721      <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>
    17311725      </ul>
    17321726      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
     
    17801774         <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
    17811775            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 Host header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;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&nbsp;5.4</a>, containing the target URI's authority component (excluding any userinfo).
    17831777         </p>
    17841778      </div>
     
    18511845      <div id="rfc.iref.e.1"></div>
    18521846      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<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".
    18561849      </p>
    18571850      <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
     
    18631856      </p>
    18641857      <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 the
    1866          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's incoming 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.
    18681861      </p>
    18691862      <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
     
    18831876</pre> <div id="rfc.figure.u.58"></div>
    18841877      <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 Host field-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 Host 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
     1878</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
    18881881         the effective request URI's authority component.
    18891882      </p>
     
    19011894         except as noted above to replace an empty path with "/" or "*".
    19021895      </p>
    1903       <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;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&nbsp;6.1</a>.
    19041897      </p>
    19051898      <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a>&nbsp;<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>
     
    19151908      <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
    19161909      <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>
    19251921      </ul>
    19261922      <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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;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&nbsp;6.1</a>).
    19281924      </p>
    19291925      <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3>
     
    20922088      </p>
    20932089      <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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;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&nbsp;6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    20952091      </p>
    20962092      <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a>&nbsp;<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".
    21002095      </p>
    21012096      <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.
    21072101      </p>
    21082102      <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&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    21092103      </p>
    21102104      <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).
    21122106      </p>
    21132107      <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&nbsp;3.3</a>.
     
    21822176         </li>
    21832177         <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"
    21852179            expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
    21862180            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.
     
    22402234         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.
    22412235      </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 Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;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&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    22432237      </p>
    22442238      <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
     
    23312325      </div>
    23322326      <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&nbsp;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&nbsp;6.1</a>).
    23342328      </p>
    23352329      <div id="rfc.table.u.1">
     
    25552549      </div>
    25562550      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<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
    25592552         details how the connection will be processed after it has been upgraded.
    25602553      </p>
     
    26722665      </p>
    26732666      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<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, Ari
     2667      <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
    26752668         Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham.
    26762669         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.
     
    27122705      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    27132706      </h2>
    2714       <table>                       
     2707      <table>                         
    27152708         <tr>
    27162709            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
     
    27352728            <td class="reference"><b id="Part6">[Part6]</b></td>
    27362729            <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&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), July&nbsp;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&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), July&nbsp;2012.
    27372735            </td>
    27382736         </tr>
     
    29282926      </p>
    29292927      <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 ought
    2931          to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests
    2932          wherein 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.
    29332931      </p>
    29342932      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
    29352933      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    29362934      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<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 Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;5.3</a>) are among the most important changes defined by HTTP/1.1.
    29382936      </p>
    29392937      <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,
    29422939         additional requirements were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing,
    29432940         most HTTP-based services are dependent upon the Host header field for targeting requests.
     
    29462943      <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
    29472944         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>.
    29492946      </p>
    29502947      <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
    29512948         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.
    29542950      </p>
    29552951      <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
     
    29802976      <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&nbsp;3.2.5</a>)
    29812977      </p>
    2982       <p id="rfc.section.A.2.p.7">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;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&nbsp;3.3</a>)
    29832979      </p>
    29842980      <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>)
     
    29972993      <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&nbsp;6.1</a>)
    29982994      </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&nbsp;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&nbsp;6.5</a>)
    30002996      </p>
    30012997      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    37723768                     </ul>
    37733769                  </li>
     3770                  <li><em>Part7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">5.6.1</a></li>
     3772                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.2">5.6.1</a></li>
     3773                     </ul>
     3774                  </li>
    37743775                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    37753776               </ul>
     
    37923793                  </li>
    37933794                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3794                   <li><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">5.6.1</a></li>
     3797                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li>
    37963798                     </ul>
    37973799                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1740 r1741  
    3636  <!ENTITY header-pragma          "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3737  <!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'/>">
    3840  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3941  <!ENTITY methods                "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    503505   that wishes to interoperate with third-party HTTP servers &MUST;
    504506   conform to HTTP user agent requirements on the gateway's inbound
    505    connection and &MUST; implement the Connection
    506    (<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.
    508510</t>
    509511<t><iref primary="true" item="tunnel"/>
     
    662664   behavior of a recipient in the absence of such a field can change.
    663665   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.
    667670</t>
    668671<t>
     
    674677   the message's HTTP version.  An unrecognized header field received
    675678   by a proxy &MUST; be forwarded downstream unless the header field's
    676    field-name is listed in the message's Connection header field
     679   field-name is listed in the message's <x:ref>Connection</x:ref> header field
    677680   (see <xref target="header.connection"/>).
    678681   These requirements allow HTTP's functionality to be enhanced without
     
    11621165   to the procedures in &cons-new-header-fields;.
    11631166   Unrecognized header fields &MUST; be forwarded by a proxy unless the
    1164    field-name is listed in the Connection header field
     1167   field-name is listed in the <x:ref>Connection</x:ref> header field
    11651168   (<xref target="header.connection"/>) or the proxy is specifically
    11661169   configured to block or otherwise transform such fields.
     
    14741477<t>
    14751478   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,
    14781481   even if the method does not define any use for a message body.
    14791482</t>
     
    14831486   status code (<xref target="status-code"/>).
    14841487   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 been
    1487    if the request method had been GET.
    1488    <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
    1489    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.
    14901493   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
    14911494   <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
     
    15871590  <x:anchor-alias value="Content-Length"/>
    15881591<t>
    1589    When a message does not have a Transfer-Encoding header field and the
    1590    payload body length can be determined prior to being transferred, a
     1592   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
    15911594   Content-Length header field &SHOULD; be sent to indicate the length of the
    15921595   payload body that is either present as the message body, for requests
     
    16571660     Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the
    16581661     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.
    16611665    </t></x:lt>
    16621666    <x:lt><t>
    1663      If a Transfer-Encoding header field is present
     1667     If a <x:ref>Transfer-Encoding</x:ref> header field is present
    16641668     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    16651669     is the final encoding, the message body length is determined by reading
     
    16681672    </t>
    16691673    <t>
    1670      If a Transfer-Encoding header field is present in a response and the
    1671      "chunked" transfer-coding is not the final encoding, the message body
    1672      length is determined by reading the connection until it is closed by
    1673      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.
    16741678     If a Transfer-Encoding header field is present in a request and the
    16751679     "chunked" transfer-coding is not the final encoding, the message body
     
    16781682    </t>
    16791683    <t>
    1680      If a message is received with both a Transfer-Encoding header field
    1681      and a Content-Length header field, the Transfer-Encoding overrides
    1682      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.
    16831687     Such a message might indicate an attempt to perform request or response
    16841688     smuggling (bypass of security-related checks on message routing or content)
     
    16881692    </t></x:lt>
    16891693    <x:lt><t>
    1690      If a message is received without Transfer-Encoding and with either
    1691      multiple Content-Length header fields having differing field-values or
    1692      a single Content-Length header field having an invalid value, then the
    1693      message framing is invalid and &MUST; be treated as an error to
    1694      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.
    16951699     If this is a request message, the server &MUST; respond with
    16961700     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
     
    17021706    </t></x:lt>
    17031707    <x:lt><t>
    1704      If a valid Content-Length header field
    1705      is present without Transfer-Encoding, its decimal value defines the
     1708     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
    17061710     message body length in octets.  If the actual number of octets sent in
    17071711     the message is less than the indicated Content-Length, the recipient
     
    17361740<t>
    17371741   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>.
    17391744</t>
    17401745<t>
    17411746   Unless a transfer-coding other than "chunked" has been applied,
    17421747   a client that sends a request containing a message body &SHOULD;
    1743    use a valid Content-Length header field if the message body length
    1744    is known in advance, rather than the "chunked" encoding, since some
     1748   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
    17451750   existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    17461751   status code even though they understand the chunked encoding.  This
     
    17511756<t>
    17521757   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 will
    1754    handle HTTP/1.1 (or later) requests; such knowledge can be in the form
    1755    of specific user configuration or by remembering the version of a prior
    1756    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.
    17571762</t>
    17581763</section>
     
    17771782   A message body that uses the chunked transfer encoding is
    17781783   incomplete if the zero-sized chunk that terminates the encoding has not
    1779    been received.  A message that uses a valid Content-Length is incomplete
    1780    if the size of the message body received (in octets) is less than the
    1781    value given by Content-Length.  A response that has neither chunked
     1784   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
    17821787   transfer encoding nor Content-Length is terminated by closure of the
    17831788   connection, and thus is considered complete regardless of the number of
     
    18661871   The HTTP Transfer Coding registry is defined in
    18671872   <xref target="transfer.coding.registry"/>.
    1868    HTTP/1.1 uses transfer-coding values in the TE header field
    1869    (<xref target="header.te"/>) and in the Transfer-Encoding header field
    1870    (<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"/>).
    18711876</t>
    18721877
     
    19211926<t>
    19221927   The trailer allows the sender to include additional HTTP header
    1923    fields at the end of the message. The Trailer header field can be
    1924    used to indicate which header fields are included in a trailer (see
     1928   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
    19251930   <xref target="header.trailer"/>).
    19261931</t>
     
    19301935   true:
    19311936  <list style="numbers">
    1932     <t>the request included a TE header field that indicates "trailers" is
    1933      acceptable in the transfer-coding of the  response, as described in
    1934     <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>
    19351940     
    19361941    <t>the trailer fields consist entirely of optional metadata, and the
     
    20762081<t>
    20772082   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.
    20802086</t>
    20812087<t>
     
    21202126  <x:anchor-alias value="qvalue"/>
    21212127<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 various
    2125    negotiable parameters.  A weight is normalized to a real number in
    2126    the range 0 through 1, where 0 is the minimum and 1 the maximum
    2127    value. If a parameter has a quality value of 0, then content with
     2128   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
    21282134   this parameter is "not acceptable" for the client. HTTP/1.1
    21292135   applications &MUST-NOT; generate more than three digits after the
     
    21712177   include the following header fields:
    21722178  <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>
    21762182  </list>
    21772183</t>
     
    22732279   If the target URI's path component is empty, then the client &MUST; send
    22742280   "/" as the path within the origin-form of request-target.
    2275    A Host header field is also sent, as defined in
     2281   A <x:ref>Host</x:ref> header field is also sent, as defined in
    22762282   <xref target="header.host"/>, containing the target URI's
    22772283   authority component (excluding any userinfo).
     
    24282434   A server that receives an HTTP request message &MUST; reconstruct
    24292435   the user agent's original target URI, based on the pieces of information
    2430    learned from the request-target, Host, and connection context, in order
    2431    to identify the intended target resource and properly service the request.
    2432    The URI derived from this reconstruction process is referred to as the
    2433    "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".
    24342440</t>
    24352441<t>
     
    24492455   If the request-target is in authority-form, then the effective
    24502456   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 default
    2454    host name configured for the server, a colon (":"), and the connection's
    2455    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.
    24562462</t>
    24572463<t>
     
    25032509<t>
    25042510   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 a
    2506    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 for
     2511   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
    25112517   something unique to a particular host) in order to guess the
    25122518   effective request URI's authority component.
     
    25422548<t>
    25432549   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"/>.
    25452552</t>
    25462553
     
    25692576   The following HTTP/1.1 header fields are hop-by-hop header fields:
    25702577  <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>
    25792586  </list>
    25802587</t>
     
    25832590</t>
    25842591<t>
    2585    Other hop-by-hop header fields &MUST; be listed in a Connection header field
    2586    (<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"/>).
    25872594</t>
    25882595</section>
     
    29302937   Persistent connections provide a mechanism by which a client and a
    29312938   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
    29342942   connection.
    29352943</t>
     
    29382946<t>
    29392947   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 including
    2941    the connection option "close" was sent in the request. If the server
    2942    chooses to close the connection immediately after sending the
     2948   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
    29432951   response, it &SHOULD; send a Connection header field including the
    29442952   connection option "close".
     
    29472955   An HTTP/1.1 client &MAY; expect a connection to remain open, but would
    29482956   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 case
    2950    the client does not want to maintain a connection for more than that
    2951    request, it &SHOULD; send a Connection header field including the
     2957   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
    29522960   connection option "close".
    29532961</t>
    29542962<t>
    29552963   If either the client or the server sends the "close" option in the
    2956    Connection header field, that request becomes the last one for the
    2957    connection.
     2964   <x:ref>Connection</x:ref> header field, that request becomes the last one
     2965   for the connection.
    29582966</t>
    29592967<t>
     
    32733281<t>
    32743282   The Upgrade header field only applies to the immediate connection.
    3275    Therefore, the upgrade keyword &MUST; be supplied within a Connection
    3276    header field (<xref target="header.connection"/>) whenever Upgrade is present in an
    3277    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.
    32783286</t>
    32793287<t>
     
    33763384   Furthermore, the header field-name "Close" shall be registered as
    33773385   "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>"
    33793387   header field (<xref target="header.connection"/>).
    33803388</t>
     
    36393647<t>
    36403648   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 and
    3643    an optional set of specifications that details how the connection
     3649   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
    36443652   will be processed after it has been upgraded.
    36453653</t>
     
    42224230</reference>
    42234231
     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
    42244256<reference anchor="RFC5234">
    42254257  <front>
     
    48334865   Since HTTP/0.9 did not support header fields in a request,
    48344866   there is no mechanism for it to support name-based virtual
    4835    hosts (selection of resource by inspection of the Host header
     4867   hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header
    48364868   field).  Any server that implements name-based virtual hosts
    48374869   ought to disable support for HTTP/0.9.  Most requests that
     
    48504882<section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
    48514883<t>
    4852    The requirements that clients and servers support the Host header
    4853    field (<xref target="header.host"/>), report an error if it is
     4884   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
    48544886   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    48554887   are among the most important changes defined by HTTP/1.1.
     
    48594891   addresses and servers; there was no other established mechanism for
    48604892   distinguishing the intended server of a request than the IP address
    4861    to which that request was directed. The Host header field was
     4893   to which that request was directed. The <x:ref>Host</x:ref> header field was
    48624894   introduced during the development of HTTP/1.1 and, though it was
    48634895   quickly implemented by most HTTP/1.0 browsers, additional requirements
     
    48814913   with a "Connection: keep-alive" request header field. However, some
    48824914   experimental implementations of HTTP/1.0 persistent connections are faulty;
    4883    for example, if a HTTP/1.0 proxy server doesn't understand Connection, it
    4884    will erroneously forward that header to the next inbound server, which
    4885    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.
    48864918</t>
    48874919<t>
     
    49424974</t>
    49434975<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.
    49454978  (<xref target="message.body"/>)
    49464979</t>
     
    49805013</t>
    49815014<t>
    4982   Define the semantics of the "Upgrade" header field in responses other than
    4983   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"/>).
    49845017  (<xref target="header.upgrade"/>)
    49855018</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1740 r1741  
    967967      </p>
    968968      <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-Length field 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".
    970970      </p>
    971971      <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&nbsp;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.
     
    11141114      </p>
    11151115      <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 Via 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
     1116         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
    11171117         messages in an infinite loop.
    11181118      </p>
     
    11331133</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
    11341134         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
    11381140         governed by HTTP.
    11391141      </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>
    11411143      <div id="rfc.figure.u.5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    11421144Host: server.example.com:80
    11431145Proxy-Authorization: basic aGVsbG86d29ybGQ=
    11441146
    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 implementations
     1147</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
    11461148         to reject the request.
    11471149      </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 discarded
     1150      <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
    11491151         if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
    11501152      </p>
    1151       <p id="rfc.section.2.3.8.p.10">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,
    11521154         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.
    11531155      </p>
    1154       <p id="rfc.section.2.3.8.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
     1156      <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
    11551157         the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    11561158         peer undelivered, that data will be discarded.
    11571159      </p>
    1158       <p id="rfc.section.2.3.8.p.12">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.
    11591161      </p>
    11601162      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
     
    12071209         </li>
    12081210         <li>
    1209             <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 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>).
    12101212            </p>
    12111213         </li>
     
    16731675      <div id="rfc.iref.s.5"></div>
    16741676      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<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 Upgrade 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
     1677      <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
    16761678         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    16771679      </p>
     
    19871989      <div id="rfc.iref.s.31"></div>
    19881990      <h3 id="rfc.section.4.6.10"><a href="#rfc.section.4.6.10">4.6.10</a>&nbsp;<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 request
     1991      <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
    19901992         message.
    19911993      </p>
     
    20222024      <div id="rfc.iref.s.36"></div>
    20232025      <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a>&nbsp;<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 Upgrade 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.
     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.
    20252027      </p>
    20262028      <div id="rfc.figure.u.7"></div>
     
    23492351      </div>
    23502352      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<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.
    23532354      </p>
    23542355      <div id="rfc.iref.r.1"></div>
     
    23692370         in an HTTP message, it is referred to as the payload of the message.
    23702371      </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.
    23732373      </p>
    23742374      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
     
    30523052</pre><p id="rfc.section.9.17.p.4">Example:</p>
    30533053      <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 Via 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>).
     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>).
    30553055      </p>
    30563056      <div class="note" id="rfc.section.9.17.p.7">
     
    36063606      </p>
    36073607      <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 Via fields 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.
    36093609      </p>
    36103610      <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
     
    39253925      </p>
    39263926      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<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-Encoding 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.
     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.
    39283928      </p>
    39293929      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<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  
    551551   future extensions to HTTP. Content negotiation &MAY; be used to select
    552552   the appropriate response format. If no response body is included, the
    553    response &MUST; include a Content-Length field with a field-value of
    554    "0".
     553   response &MUST; include a <x:ref>Content-Length</x:ref> field with a
     554   field-value of "0".
    555555</t>
    556556<t>
     
    881881   TRACE allows the client to see what is being received at the other
    882882   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 of
    884    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.
    885885   Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
    886886   limit the length of the request chain, which is useful for testing a chain of
     
    921921   The tunneled data from the server begins immediately after the blank line
    922922   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.
    925927   A client &MUST; ignore any Content-Length or Transfer-Encoding header
    926928   fields received in a successful response.
     
    10561058    responses or requests, in all messages, only on responses to a particular
    10571059    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>
    10601063    <x:lt><t>Under what conditions intermediaries are allowed to modify the header
    10611064    field's value, insert or delete it.</t></x:lt>
     
    13471350  <x:anchor-alias value="101 (Switching Protocols)"/>
    13481351<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 a
    1351    change in the application protocol being used on this connection. The
    1352    server will switch protocols to those defined by the response's
    1353    Upgrade header field immediately after the empty line which
    1354    terminates the 101 response.
     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.
    13551358</t>
    13561359<t>
     
    19841987  <x:anchor-alias value="411 (Length Required)"/>
    19851988<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 valid
    1988    Content-Length header field containing the length of the message body
    1989    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.
    19901993</t>
    19911994</section>
     
    20532056<t>
    20542057   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.
    20572060</t>
    20582061<figure>
     
    26612664   A payload body is only present in a message when a message body is
    26622665   present, as described in &message-body;. The payload body is obtained
    2663    from the message body by decoding any Transfer-Encoding that might
    2664    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.
    26652668</t>
    26662669</section>
     
    27012704   A representation body is only present in a message when a message body is
    27022705   present, as described in &message-body;. The representation body is obtained
    2703    from the message body by decoding any Transfer-Encoding that might
    2704    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.
    27052708</t>
    27062709
     
    39383941</artwork></figure>
    39393942<t>
    3940    If the response is being forwarded through a proxy, the proxy
    3941    application &MUST-NOT; modify the Server header field. Instead, it
    3942    &MUST; include a Via field (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;).
    39433946</t>
    39443947<x:note>
     
    44784481   take special precautions regarding the transfer of header information
    44794482   that identifies the hosts behind the firewall. In particular, they
    4480    &SHOULD; remove, or replace with sanitized versions, any Via fields
    4481    generated behind the firewall.
     4483   &SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref>
     4484   fields generated behind the firewall.
    44824485</t>
    44834486<t>
     
    46454648  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    46464649  <x:source href="p1-messaging.xml" basename="p1-messaging">
     4650    <x:defines>Connection</x:defines>
    46474651    <x:defines>Content-Length</x:defines>
    46484652    <x:defines>Transfer-Encoding</x:defines>
     4653    <x:defines>Upgrade</x:defines>
    46494654    <x:defines>Via</x:defines>
    46504655  </x:source>
     
    54435448<section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
    54445449<t>
    5445    HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
    5446    Proxies/gateways &MUST; remove any transfer-coding prior to
    5447    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.
    54485453</t>
    54495454</section>
  • draft-ietf-httpbis/latest/p5-range.html

    r1740 r1741  
    771771      </h2>
    772772      <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-Length header 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,
    774774      </p>
    775775      <div id="rfc.figure.u.5"></div><pre class="text">HTTP/1.1 206 Partial Content
     
    807807      </p>
    808808      <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-Length 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
     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 <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
    810810         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.
    811811      </p>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1740 r1741  
    403403   for a set of ranges that overlap without any holes), this content is
    404404   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,
    407407</t>
    408408<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
     
    481481   content ranges in the new response and each of the selected responses.
    482482   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.
    490491</t>
    491492</section>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1740 r1741  
    10281028      <p>These <em class="bcp14">SHOULD</em> be combined as
    10291029      </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 Via header 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.
    10311031      </p>
    10321032      <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
     
    11201120         a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
    11211121      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:
    11251125      </p>
    11261126      <ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1740 r1741  
    808808<t>
    809809   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), in
    811    which case the corrected_age_value &MAY; be used as the
     810   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
    812812   corrected_initial_age.</t>
    813813<t>
     
    991991   If one or more stored GET responses can be selected (as per <xref
    992992   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:
    10031004   <list style="symbols">
    10041005      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     
    22802281    </front>
    22812282    <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>
    22832287  </reference>
    22842288
Note: See TracChangeset for help on using the changeset viewer.