Changeset 2334


Ignore:
Timestamp:
Aug 1, 2013, 3:42:01 AM (6 years ago)
Author:
fielding@…
Message:

Many changes to properly target MUST requirements by role; addresses #484

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

Legend:

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

    r2333 r2334  
    10071007         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.
    10081008      </p>
    1009       <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
    1010          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
    1011          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.1" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
     1009      <p id="rfc.section.2.6.p.7">New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely
     1010         ignored by recipients that do not recognize them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section&nbsp;3.2.1</a>.
    10121011      </p>
    10131012      <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
     
    10801079         identifier for a potential resource within that origin server's name space.
    10811080      </p>
    1082       <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that
     1081      <p id="rfc.section.2.7.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference <em class="bcp14">MUST</em> reject it as invalid.
     1082      </p>
     1083      <p id="rfc.section.2.7.1.p.5">If the host identifier is provided as an IP address, then the origin server is any listener on the indicated TCP port at that
    10831084         IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might use
    1084          a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
    1085          port for WWW services).
    1086       </p>
    1087       <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
     1085         a name resolution service, such as DNS, to find the address of a listener for that host. If the port subcomponent is empty
     1086         or not given, then TCP port 80 is assumed (the default reserved port for WWW services).
     1087      </p>
     1088      <p id="rfc.section.2.7.1.p.6">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
    10881089         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
    10891090         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
     
    10911092         authority to determine which names are valid and how they might be used.
    10921093      </p>
    1093       <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     1094      <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    10941095         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    10951096      </p>
    1096       <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     1097      <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    10971098         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    10981099         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that
     
    11001101         — it is only the authoritative interface that is specific to TCP.
    11011102      </p>
    1102       <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
     1103      <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    11031104         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    1104          even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST</em> exclude the userinfo subcomponent (and its "@" delimiter) when an "http" URI is transmitted within a message as a request
    1105          target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
     1105         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a
     1106         request target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
    11061107         of phishing attacks.
    11071108      </p>
     
    11131114      </p>
    11141115      <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
    1115          TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured, end-to-end, through the use of strong encryption prior to sending the first HTTP request.
     1116         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending
     1117         the first HTTP request.
    11161118      </p>
    11171119      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     
    12061208      </p>
    12071209      <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1208          it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1210         it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    12091211      </p>
    12101212      <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
     
    12411243      </p>
    12421244      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3>
    1243       <p id="rfc.section.3.2.1.p.1">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    1244          new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this
    1245          specification and in many other specifications outside the core standard. New header fields can be introduced without changing
    1246          the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
    1247       </p>
    1248       <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields 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.2" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
     1245      <p id="rfc.section.3.2.1.p.1">Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new
     1246         semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification
     1247         and in many other specifications outside the core standard.
     1248      </p>
     1249      <p id="rfc.section.3.2.1.p.2">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
     1250         of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.
     1251      </p>
     1252      <p id="rfc.section.3.2.1.p.3">A proxy <em class="bcp14">MUST</em> forward unrecognized header fields 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.1" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update
     1253         of deployed intermediaries.
     1254      </p>
     1255      <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    12491256      </p>
    12501257      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
     
    12561263         field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
    12571264      </p>
    1258       <p id="rfc.section.3.2.2.p.3">Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing
    1259          the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by
    1260          a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation
    1261          of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
     1265      <p id="rfc.section.3.2.2.p.3">A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics
     1266         of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order
     1267         in which header fields with the same field name are received is therefore significant to the interpretation of the combined
     1268         field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
    12621269      </p>
    12631270      <div class="note" id="rfc.section.3.2.2.p.4">
     
    13191326      </p>
    13201327      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
    1321       <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole.
    1322          Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
     1328      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole,
     1329         as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
    13231330         semantics.
    13241331      </p>
    1325       <p id="rfc.section.3.2.5.p.2">A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.
    1326       </p>
    1327       <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MUST</em> be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
    1328          that the dropped value(s) can be safely ignored without changing the response semantics.
     1332      <p id="rfc.section.3.2.5.p.2">A server ought to be prepared to receive request header fields of unbounded length and <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.
     1333      </p>
     1334      <p id="rfc.section.3.2.5.p.3">A client ought to be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
     1335         that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
    13291336      </p>
    13301337      <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
    13311338      <div id="rule.token.separators">
    1332          <p id="rfc.section.3.2.6.p.1">    Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These
    1333             special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    1334          </p>
     1339         <p id="rfc.section.3.2.6.p.1">    Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters.</p>
    13351340      </div>
    13361341      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#rule.token.separators" class="smpl">word</a>           = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
     
    14001405         applied for transport efficiency or security from those that are characteristics of the selected resource.
    14011406      </p>
    1402       <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> implement the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. If chunked is applied
    1403          to a payload body, the sender <em class="bcp14">MUST NOT</em> apply chunked more than once (i.e., chunking an already chunked message is not allowed). If any transfer coding is applied
    1404          to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding is applied
    1405          to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
     1407      <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer
     1408         coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than
     1409         chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
    14061410      </p>
    14071411      <div id="rfc.figure.u.27"></div>
     
    14961500         <li>
    14971501            <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
    1498                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> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
     1502               framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable 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> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
    14991503            </p>
    15001504         </li>
     
    16201624      <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
    16211625         might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
    1622          status. The trailer <em class="bcp14">MUST NOT</em> contain fields that need to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
     1626         status. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a field that needs to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
    16231627      </p>
    16241628      <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
    1625          the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> send a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
     1629         the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
    16261630         prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed
    16271631         and the recipient wishes to confirm an integrity check on the fly.
    16281632      </p>
    16291633      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    1630 </pre><p id="rfc.section.4.1.1.p.4">If no <a href="#header.trailer" class="smpl">Trailer</a> header field is present, the sender of a chunked message body <em class="bcp14">SHOULD</em> send an empty trailer.
    1631       </p>
    1632       <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer coding unless at least one of the following is true:
     1634</pre><p id="rfc.section.4.1.1.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true:
    16331635      </p>
    16341636      <ol>
     
    16361638         </li>
    16371639         <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to
    1638             the server where the field originated) without receiving that metadata. In other words, the server that generated the header
    1639             field is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.
     1640            the generating server) without receiving that metadata. In other words, the generating server is willing to accept the possibility
     1641            that the trailer fields might be silently discarded along the path to the client.
    16401642         </li>
    16411643      </ol>
    1642       <p id="rfc.section.4.1.1.p.6">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
     1644      <p id="rfc.section.4.1.1.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
    16431645         proxy and forwarded to an HTTP/1.0 recipient.
    16441646      </p>
     
    16611663  Remove "chunked" from Transfer-Encoding
    16621664  Remove Trailer from existing header fields
    1663 </pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to receive and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1665</pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    16641666      </p>
    16651667      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
     
    17111713         no transfer coding is always acceptable.
    17121714      </p>
    1713       <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
     1715      <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
    17141716      </p>
    17151717      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
     
    17661768      <p id="rfc.section.5.3.p.4">The most common form of request-target is the <dfn>origin-form</dfn>. When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below),
    17671769         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
    1768          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).
     1770         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>.
    17691771      </p>
    17701772      <p id="rfc.section.5.3.p.5">For example, a client wishing to retrieve a representation of the resource identified as</p>
     
    17921794         </p>
    17931795      </div>
    1794       <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
     1796      <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
    17951797      </p>
    17961798      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     
    18151817      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    18161818      <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server
    1817          to distinguish among resources while servicing requests for multiple host names on a single IP address. Since the Host field-value
    1818          is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
     1819         to distinguish among resources while servicing requests for multiple host names on a single IP address.
    18191820      </p>
    18201821      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.86"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    1821 </pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then the Host
    1822          field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    1823       </p>
    1824       <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
     1822</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@"
     1823         delimiter (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value.
     1824      </p>
     1825      <p id="rfc.section.5.4.p.4">Since the Host field-value is critical information for handling a request, a user agent <em class="bcp14">SHOULD</em> generate Host as the first header field following the request-line.
     1826      </p>
     1827      <p id="rfc.section.5.4.p.5">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    18251828      <div id="rfc.figure.u.46"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    18261829Host: www.example.org
    1827 </pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information
    1828          to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    1829       </p>
    1830       <p id="rfc.section.5.4.p.7">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If
    1831          the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
    1832       </p>
    1833       <p id="rfc.section.5.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
     1830</pre><p id="rfc.section.5.4.p.7">A client <em class="bcp14">MUST</em> send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the
     1831         Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
     1832      </p>
     1833      <p id="rfc.section.5.4.p.8">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy
     1834         that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
     1835      </p>
     1836      <p id="rfc.section.5.4.p.9">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    18341837         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    18351838         relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache,
    18361839         without first verifying that the intercepted connection is targeting a valid IP address for that host.
    18371840      </p>
    1838       <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
     1841      <p id="rfc.section.5.4.p.10">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
    18391842         one Host header field or a Host header field with an invalid field-value.
    18401843      </p>
     
    18911894         enhance (or interfere) with either direction of the stream.
    18921895      </p>
    1893       <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
    1894       </p>
    1895       <p id="rfc.section.5.7.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1896      <p id="rfc.section.5.7.p.2">An intermediary not acting as a tunnel <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.3" title="Connection">Section&nbsp;6.1</a>, and exclude fields from being forwarded that are only intended for the incoming connection.
     1897      </p>
     1898      <p id="rfc.section.5.7.p.3">An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize
     1899         its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.
    18961900      </p>
    18971901      <div id="rfc.iref.v.1"></div>
     
    19201924      </p>
    19211925      <p id="rfc.section.5.7.1.p.6">The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded
    1922          the message. However, if the real host is considered to be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    1923       </p>
    1924       <p id="rfc.section.5.7.1.p.7">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     1926         the message. However, if the real host is considered to be sensitive information, a sender <em class="bcp14">MAY</em> replace it with a pseudonym. If a port is not provided, a recipient <em class="bcp14">MAY</em> interpret that as meaning it was received on the default TCP port, if any, for the received-protocol.
     1927      </p>
     1928      <p id="rfc.section.5.7.1.p.7">A sender <em class="bcp14">MAY</em> generate comments in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and a recipient <em class="bcp14">MAY</em> remove them prior to forwarding the message.
    19251929      </p>
    19261930      <p id="rfc.section.5.7.1.p.8">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     
    19291933      </p>
    19301934      <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net
    1931 </pre><p id="rfc.section.5.7.1.p.10">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    1932          the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    1933       </p>
    1934       <p id="rfc.section.5.7.1.p.11">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
     1935</pre><p id="rfc.section.5.7.1.p.10">An intermediary used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     1936         such an intermediary <em class="bcp14">SHOULD</em> replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.
     1937      </p>
     1938      <p id="rfc.section.5.7.1.p.11">An intermediary <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
    19351939         values. For example,
    19361940      </p>
     
    20142018      </p>
    20152019      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    2016 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">MUST</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
     2020</pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the sender is going to close the connection after the current
     2021         request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
    20172022      </p>
    20182023      <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message.
     
    20432048      <p id="rfc.section.6.3.p.4">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.
    20442049      </p>
    2045       <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a 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>. A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
     2050      <p id="rfc.section.6.3.p.5">In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined
     2051         by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>. A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
    20462052         on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request.
    20472053      </p>
     
    20642070         or fixing any changes that were partially applied, and then automatically retrying the requests that failed.
    20652071      </p>
    2066       <p id="rfc.section.6.3.1.p.4">An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if it fails.
     2072      <p id="rfc.section.6.3.1.p.4">A client <em class="bcp14">SHOULD NOT</em> automatically retry a failed automatic retry.
    20672073      </p>
    20682074      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h3>
    20692075      <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    20702076      </p>
    2071       <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">MUST</em> be prepared to retry those requests if the connection closes before it receives all of the corresponding responses. A client
    2072          that assumes a persistent connection and pipelines immediately after connection establishment <em class="bcp14">MUST NOT</em> pipeline on a retry connection until it knows the connection is persistent.
    2073       </p>
    2074       <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method until the final response status code for that method has been received, unless
     2077      <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
     2078         requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client <em class="bcp14">MUST NOT</em> pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused
     2079         an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset
     2080         problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
     2081      </p>
     2082      <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
    20752083         the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    20762084      </p>
     
    21152123      <div id="rfc.iref.c.14"></div>
    21162124      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2>
    2117       <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
     2125      <p id="rfc.section.6.6.p.1">The <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>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
    21182126      </p>
    21192127      <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.
     
    21502158  <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21512159</pre><p id="rfc.section.6.7.p.3">A server that sends a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response <em class="bcp14">MUST</em> send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol
    2152          layers are being switched, the new protocols <em class="bcp14">MUST</em> be listed in layer-ascending order. A server <em class="bcp14">MUST NOT</em> switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server <em class="bcp14">MAY</em> choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such
     2160         layers are being switched, the sender <em class="bcp14">MUST</em> list the protocols in layer-ascending order. A server <em class="bcp14">MUST NOT</em> switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server <em class="bcp14">MAY</em> choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such
    21532161         as the nature of the request or the current load on the server.
    21542162      </p>
     
    21662174</pre><p id="rfc.section.6.7.p.7">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    21672175         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s)
    2168          chosen, although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field.
     2176         chosen. However, immediately after sending the 101 response, the server is expected to continue responding to the original
     2177         request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to
     2178         satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).
    21692179      </p>
    21702180      <p id="rfc.section.6.7.p.8">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first
     
    21812191[... data stream switches to HTTP/2.0 with an appropriate response
    21822192(as defined by new protocol) to the "GET /hello.txt" request ...]
    2183 </pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send 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>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
     2193</pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
    21842194         that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
    21852195      </p>
     
    22152225                  <td class="left">http</td>
    22162226                  <td class="left">standard</td>
    2217                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>
     2227                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>
    22182228                  </td>
    22192229               </tr>
     
    22712281      </div>
    22722282      <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
    2273          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.8" title="Connection">Section&nbsp;6.1</a>).
     2283         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.7" title="Connection">Section&nbsp;6.1</a>).
    22742284      </p>
    22752285      <div id="rfc.table.u.1">
     
    29812991      <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>)
    29822992      </p>
    2983       <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
     2993      <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>)
    29842994      </p>
    29852995      <p id="rfc.section.A.2.p.28">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
    2986          in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
     2996         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
    29872997      </p>
    29882998      <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
     
    32793289                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li>
    32803290                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3281                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3291                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">7.1</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
    32823292                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    32833293                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3284                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3294                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">7.1</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
    32853295                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
    32863296               </ul>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2333 r2334  
    730730</t>
    731731<t>
    732    New header fields can be defined such that, when they are
    733    understood by a recipient, they might override or enhance the
    734    interpretation of previously defined header fields.  When an
    735    implementation receives an unrecognized header field, the recipient
    736    &MUST; ignore that header field for local processing regardless of
    737    the message's HTTP version.  An unrecognized header field received
    738    by a proxy &MUST; be forwarded downstream unless the header field's
    739    field-name is listed in the message's <x:ref>Connection</x:ref> header field
    740    (see <xref target="header.connection"/>).
    741    These requirements allow HTTP's functionality to be enhanced without
    742    requiring prior update of deployed intermediaries.
     732   New header fields can be introduced without changing the protocol version
     733   if their defined semantics allow them to be safely ignored by recipients
     734   that do not recognize them. Header field extensibility is discussed in
     735   <xref target="field.extensibility"/>.
    743736</t>
    744737<t>
     
    889882</t>
    890883<t>
     884   A sender &MUST-NOT; generate an "http" URI with an empty host identifier.
     885   A recipient that processes such a URI reference &MUST; reject it as invalid.
     886</t>
     887<t>
    891888   If the host identifier is provided as an IP address,
    892889   then the origin server is any listener on the indicated TCP port at
     
    895892   resolution service, such as DNS, to find the address of a listener
    896893   for that host.
    897    The host &MUST-NOT; be empty; if an "http" URI is received with an
    898    empty host, then it &MUST; be rejected as invalid.
    899894   If the port subcomponent is empty or not given, then TCP port 80 is
    900895   assumed (the default reserved port for WWW services).
     
    940935   invocation options, configuration files, or bookmark lists, even
    941936   though such usage might expose a user identifier or password.
    942    Senders &MUST; exclude the userinfo subcomponent (and its "@"
    943    delimiter) when an "http" URI is transmitted within a message as a
     937   Senders &MUST-NOT; generate the userinfo subcomponent (and its "@"
     938   delimiter) when an "http" URI reference is generated within a message as a
    944939   request target or header field value.
    945940   Recipients of an "http" URI reference &SHOULD; parse for userinfo and
     
    964959   requirements for the "https" scheme, except that a default TCP port
    965960   of 443 is assumed if the port subcomponent is empty or not given,
    966    and the TCP connection &MUST; be secured, end-to-end, through the
    967    use of strong encryption prior to sending the first HTTP request.
     961   and the user agent &MUST; ensure that its connection to the origin
     962   server is secured through the use of strong encryption, end-to-end,
     963   prior to sending the first HTTP request.
    968964</t>
    969965<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"><!--terminal production--></iref>
     
    11571153   A server that receives a method longer than any that it implements
    11581154   &SHOULD; respond with a <x:ref>501 (Not Implemented)</x:ref> status code.
    1159    A server &MUST; be prepared to receive URIs of unbounded length and
    1160    respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received
    1161    request-target would be longer than the server wishes to handle
    1162    (see &status-414;).
     1155   A server ought to be prepared to receive URIs of unbounded length, as
     1156   described in <xref target="conformance"/>, and &MUST; respond with a
     1157   <x:ref>414 (URI Too Long)</x:ref> status code if the received
     1158   request-target is longer than the server wishes to parse (see &status-414;).
    11631159</t>
    11641160<t>
     
    12381234<section title="Field Extensibility" anchor="field.extensibility">
    12391235<t>
    1240    HTTP header fields are fully extensible: there is no limit on the
     1236   Header fields are fully extensible: there is no limit on the
    12411237   introduction of new field names, each presumably defining new semantics,
    12421238   nor on the number of header fields used in a given message.  Existing
    12431239   fields are defined in each part of this specification and in many other
    12441240   specifications outside the core standard.
    1245    New header fields can be introduced without changing the protocol version
    1246    if their defined semantics allow them to be safely ignored by recipients
    1247    that do not recognize them.
    1248 </t>
    1249 <t>
    1250    New HTTP header fields ought to be registered with IANA in the
    1251    Message Header Field Registry, as described in &iana-header-registry;.
     1241</t>
     1242<t>
     1243   New header fields can be defined such that, when they are understood by a
     1244   recipient, they might override or enhance the interpretation of previously
     1245   defined header fields, define preconditions on request evaluation, or
     1246   refine the meaning of responses.
     1247</t>
     1248<t>
    12521249   A proxy &MUST; forward unrecognized header fields unless the
    12531250   field-name is listed in the <x:ref>Connection</x:ref> header field
     
    12551252   configured to block, or otherwise transform, such fields.
    12561253   Other recipients &SHOULD; ignore unrecognized header fields.
     1254   These requirements allow HTTP's functionality to be enhanced without
     1255   requiring prior update of deployed intermediaries.
     1256</t>
     1257<t>
     1258   All defined header fields ought to be registered with IANA in the
     1259   Message Header Field Registry, as described in &iana-header-registry;.
    12571260</t>
    12581261</section>
     
    12771280</t>
    12781281<t>
    1279    Multiple header fields with the same field name can be combined into
    1280    one "field-name: field-value" pair, without changing the semantics of the
    1281    message, by appending each subsequent field value to the combined
     1282   A recipient &MAY; combine multiple header fields with the same field name
     1283   into one "field-name: field-value" pair, without changing the semantics of
     1284   the message, by appending each subsequent field value to the combined
    12821285   field value in order, separated by a comma. The order in which
    12831286   header fields with the same field name are received is therefore
     
    14111414<t>
    14121415   HTTP does not place a pre-defined limit on the length of each header field
    1413    or on the length of the header block as a whole.  Various ad-hoc
    1414    limitations on individual header field length are found in practice,
    1415    often depending on the specific field semantics.
    1416 </t>
    1417 <t>
    1418    A server &MUST; be prepared to receive request header fields of unbounded
    1419    length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref>
    1420    status code if the received header field(s) are larger than the server
    1421    wishes to process.
    1422 </t>
    1423 <t>
    1424    A client &MUST; be prepared to receive response header fields of unbounded
    1425    length. A client &MAY; discard or truncate received header fields that are
    1426    larger than the client wishes to process if the field semantics are such
    1427    that the dropped value(s) can be safely ignored without changing the
    1428    response semantics.
     1416   or on the length of the header block as a whole, as described in
     1417   <xref target="conformance"/>. Various ad-hoc limitations on individual
     1418   header field length are found in practice, often depending on the specific
     1419   field semantics.
     1420</t>
     1421<t>
     1422   A server ought to be prepared to receive request header fields of unbounded
     1423   length and &MUST; respond with an appropriate
     1424   <x:ref>4xx (Client Error)</x:ref> status code if the received header
     1425   field(s) are larger than the server wishes to process.
     1426</t>
     1427<t>
     1428   A client ought to be prepared to receive response header fields of
     1429   unbounded length.
     1430   A client &MAY; discard or truncate received header fields that are larger
     1431   than the client wishes to process if the field semantics are such that the
     1432   dropped value(s) can be safely ignored without changing the
     1433   message framing or response semantics.
    14291434</t>
    14301435</section>
     
    14371442  <x:anchor-alias value="word"/>
    14381443   Many HTTP header field values consist of words (token or quoted-string)
    1439    separated by whitespace or special characters. These special characters
    1440    &MUST; be in a quoted string to be used within a parameter value (as defined
    1441    in <xref target="transfer.codings"/>).
     1444   separated by whitespace or special characters.
    14421445</t>
    14431446<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="word"/><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="special"><!--unused production--></iref>
     
    15741577</t>
    15751578<t>
    1576    All HTTP/1.1 recipients &MUST; implement the chunked transfer coding
     1579   All HTTP/1.1 recipients &MUST; be able to parse the chunked transfer coding
    15771580   (<xref target="chunked.encoding"/>) because it plays a crucial role in
    15781581   framing messages when the payload body size is not known in advance.
    1579    If chunked is applied to a payload body, the sender &MUST-NOT; apply
    1580    chunked more than once (i.e., chunking an already chunked message is not
    1581    allowed).
    1582    If any transfer coding is applied to a request payload body, the
    1583    sender &MUST; apply chunked as the final transfer coding to ensure that
    1584    the message is properly framed.
    1585    If any transfer coding is applied to a response payload body, the
    1586    sender &MUST; either apply chunked as the final transfer coding or
    1587    terminate the message by closing the connection.
     1582   A sender &MUST-NOT; apply chunked more than once to a message body
     1583   (i.e., chunking an already chunked message is not allowed).
     1584   If any transfer coding other than chunked is applied to a request payload
     1585   body, the sender &MUST; apply chunked as the final transfer coding to
     1586   ensure that the message is properly framed.
     1587   If any transfer coding other than chunked is applied to a response payload
     1588   body, the sender &MUST; either apply chunked as the final transfer coding
     1589   or terminate the message by closing the connection.
    15881590</t>
    15891591<figure><preamble>
     
    17771779     either multiple <x:ref>Content-Length</x:ref> header fields having
    17781780     differing field-values or a single Content-Length header field having an
    1779      invalid value, then the message framing is invalid and &MUST; be treated
    1780      as an error to prevent request or response smuggling.
     1781     invalid value, then the message framing is invalid and
     1782     the recipient &MUST; treat it as an unrecoverable error to prevent
     1783     request or response smuggling.
    17811784     If this is a request message, the server &MUST; respond with
    17821785     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    1783      If this is a response message received by a proxy, the proxy
    1784      &MUST; close the connection to the server, discard the received response,
    1785      and send a <x:ref>502 (Bad Gateway)</x:ref> response to the client.
    1786      If this is a response message received by a user agent, it &MUST; be
    1787      treated as an error by discarding the message and closing the connection.
     1786     If this is a response message received by a proxy,
     1787     the proxy &MUST; close the connection to the server, discard the received
     1788     response, and send a <x:ref>502 (Bad Gateway)</x:ref> response to the
     1789     client.
     1790     If this is a response message received by a user agent,
     1791     the user agent &MUST; close the connection to the server and discard the
     1792     received response.
    17881793    </t></x:lt>
    17891794    <x:lt><t>
     
    20232028   generated while the message body is sent, such as a message integrity
    20242029   check, digital signature, or post-processing status.
    2025    The trailer &MUST-NOT; contain fields that need to be known before a
    2026    recipient processes the body, such as <x:ref>Transfer-Encoding</x:ref>,
    2027    <x:ref>Content-Length</x:ref>, and <x:ref>Trailer</x:ref>.
     2030   A sender &MUST-NOT; generate a trailer containing a field that needs to be
     2031   known before a recipient processes the body, such as
     2032   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, and
     2033   <x:ref>Trailer</x:ref>.
    20282034</t>
    20292035<t>
    20302036   When a message includes a message body encoded with the chunked
    20312037   transfer coding and the sender desires to send metadata in the form of
    2032    trailer fields at the end of the message, the sender &SHOULD; send a
     2038   trailer fields at the end of the message, the sender &SHOULD; generate a
    20332039   <x:ref>Trailer</x:ref> header field before the message body to indicate
    20342040   which fields will be present in the trailers. This allows the recipient
     
    20412047</artwork></figure>
    20422048<t>
    2043    If no <x:ref>Trailer</x:ref> header field is present, the sender of a
    2044    chunked message body &SHOULD; send an empty trailer.
    2045 </t>
    2046 <t>
    2047    A server &MUST; send an empty trailer with the chunked transfer coding
     2049   A server &MUST; generate an empty trailer with the chunked transfer coding
    20482050   unless at least one of the following is true:
    20492051  <list style="numbers">
     
    20532055     
    20542056    <t>the trailer fields consist entirely of optional metadata and the
    2055     recipient could use the message (in a manner acceptable to the server where
    2056     the field originated) without receiving that metadata. In other words,
    2057     the server that generated the header field is willing to accept the
    2058     possibility that the trailer fields might be silently discarded along
    2059     the path to the client.</t>
     2057    recipient could use the message (in a manner acceptable to the generating
     2058    server) without receiving that metadata. In other words, the generating
     2059    server is willing to accept the possibility that the trailer fields might
     2060    be silently discarded along the path to the client.</t>
    20602061  </list>
    20612062</t>
     
    20912092</artwork></figure>
    20922093<t>
    2093    All recipients &MUST; be able to receive and decode the
     2094   All recipients &MUST; be able to parse and decode the
    20942095   chunked transfer coding and &MUST; ignore chunk-ext extensions
    20952096   they do not understand.
     
    23102311   "/" as the path within the origin-form of request-target.
    23112312   A <x:ref>Host</x:ref> header field is also sent, as defined in
    2312    <xref target="header.host"/>, containing the target URI's
    2313    authority component (excluding any userinfo).
     2313   <xref target="header.host"/>.
    23142314</t>
    23152315<t>
     
    23602360</t>
    23612361<t>
    2362    The <x:dfn>authority-form</x:dfn> of request-target is only used for CONNECT requests
    2363    (&CONNECT;).  When making a CONNECT request to establish a tunnel through
    2364    one or more proxies, a client &MUST; send only the target URI's
    2365    authority component (excluding any userinfo) as the request-target.
    2366    For example,
     2362   The <x:dfn>authority-form</x:dfn> of request-target is only used for
     2363   CONNECT requests (&CONNECT;). When making a CONNECT request to establish a
     2364   tunnel through one or more proxies, a client &MUST; send only the target
     2365   URI's authority component (excluding any userinfo and its "@" delimiter) as
     2366   the request-target. For example,
    23672367</t>
    23682368<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     
    24122412   information from the target URI, enabling the origin
    24132413   server to distinguish among resources while servicing requests
    2414    for multiple host names on a single IP address.  Since the Host
    2415    field-value is critical information for handling a request, it
    2416    &SHOULD; be sent as the first header field following the request-line.
     2414   for multiple host names on a single IP address.
    24172415</t>
    24182416<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
     
    24202418</artwork></figure>
    24212419<t>
    2422    A client &MUST; send a Host header field in all HTTP/1.1 request
    2423    messages.  If the target URI includes an authority component, then
    2424    the Host field-value &MUST; be identical to that authority component
    2425    after excluding any userinfo (<xref target="http.uri"/>).
     2420   A client &MUST; send a Host header field in all HTTP/1.1 request messages.
     2421   If the target URI includes an authority component, then a client &MUST;
     2422   send a field-value for Host that is identical to that authority
     2423   component, excluding any userinfo subcomponent and its "@" delimiter
     2424   (<xref target="http.uri"/>).
    24262425   If the authority component is missing or undefined for the target URI,
    2427    then the Host header field &MUST; be sent with an empty field-value.
     2426   then a client &MUST; send a Host header field with an empty field-value.
     2427</t>
     2428<t>
     2429   Since the Host field-value is critical information for handling a request,
     2430   a user agent &SHOULD; generate Host as the first header field following the
     2431   request-line.
    24282432</t>
    24292433<t>
     
    24362440</artwork></figure>
    24372441<t>
    2438    The Host header field &MUST; be sent in an HTTP/1.1 request even
     2442   A client &MUST; send a Host header field in an HTTP/1.1 request even
    24392443   if the request-target is in the absolute-form, since this
    24402444   allows the Host information to be forwarded through ancient HTTP/1.0
     
    24452449   request-target, the proxy &MUST; ignore the received
    24462450   Host header field (if any) and instead replace it with the host
    2447    information of the request-target.  If the proxy forwards the request,
    2448    it &MUST; generate a new Host field-value based on the received
     2451   information of the request-target.  A proxy that forwards such a request
     2452   &MUST; generate a new Host field-value based on the received
    24492453   request-target rather than forward the received Host field-value.
    24502454</t>
     
    25882592</t>
    25892593<t>
    2590    Intermediaries that forward a message &MUST; implement the
     2594   An intermediary not acting as a tunnel &MUST; implement the
    25912595   <x:ref>Connection</x:ref> header field, as specified in
    2592    <xref target="header.connection"/>, to exclude fields that are only
    2593    intended for the incoming connection.
    2594 </t>
    2595 <t>
    2596    In order to avoid request loops, a proxy that forwards requests to other
    2597    proxies &MUST; be able to recognize and exclude all of its own server
    2598    names, including any aliases, local variations, or literal IP addresses.
     2596   <xref target="header.connection"/>, and exclude fields from being forwarded
     2597   that are only intended for the incoming connection.
     2598</t>
     2599<t>
     2600   An intermediary &MUST-NOT; forward a message to itself unless it is
     2601   protected from an infinite request loop. In general, an intermediary ought
     2602   to recognize its own server names, including any aliases, local variations,
     2603   or literal IP addresses, and respond to such requests directly.
    25992604</t>
    26002605
     
    26492654   The received-by field is normally the host and optional port number of a
    26502655   recipient server or client that subsequently forwarded the message.
    2651    However, if the real host is considered to be sensitive information, it
    2652    &MAY; be replaced by a pseudonym. If the port is not given, it &MAY; be
    2653    assumed to be the default port of the received-protocol.
    2654 </t>
    2655 <t>
    2656    Comments &MAY; be used in the Via header field to identify the software
    2657    of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
     2656   However, if the real host is considered to be sensitive information, a
     2657   sender &MAY; replace it with a pseudonym. If a port is not provided,
     2658   a recipient &MAY; interpret that as meaning it was received on the default
     2659   TCP port, if any, for the received-protocol.
     2660</t>
     2661<t>
     2662   A sender &MAY; generate comments in the Via header field to identify the
     2663   software of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
    26582664   <x:ref>Server</x:ref> header fields. However, all comments in the Via field
    2659    are optional and &MAY; be removed by any recipient prior to forwarding the
     2665   are optional and a recipient &MAY; remove them prior to forwarding the
    26602666   message.
    26612667</t>
     
    26722678</artwork></figure>
    26732679<t>
    2674    A proxy or gateway used as a portal through a network firewall
     2680   An intermediary used as a portal through a network firewall
    26752681   &SHOULD-NOT; forward the names and ports of hosts within the firewall
    2676    region unless it is explicitly enabled to do so. If not enabled, the
    2677    received-by host of any host behind the firewall &SHOULD; be replaced
    2678    by an appropriate pseudonym for that host.
    2679 </t>
    2680 <t>
    2681    A proxy or gateway &MAY; combine an ordered subsequence of Via header
     2682   region unless it is explicitly enabled to do so. If not enabled, such an
     2683   intermediary &SHOULD; replace each received-by host of any host behind the
     2684   firewall by an appropriate pseudonym for that host.
     2685</t>
     2686<t>
     2687   An intermediary &MAY; combine an ordered subsequence of Via header
    26822688   field entries into a single such entry if the entries have identical
    26832689   received-protocol values. For example,
     
    28592865</artwork></figure>
    28602866<t>
    2861    in either the request or the response header fields indicates that
    2862    the connection &MUST; be closed after the current request/response
     2867   in either the request or the response header fields indicates that the
     2868   sender is going to close the connection after the current request/response
    28632869   is complete (<xref target="persistent.tear-down"/>).
    28642870</t>
     
    29182924</t>
    29192925<t>
    2920    In order to remain persistent, all messages on a connection &MUST;
     2926   In order to remain persistent, all messages on a connection need to
    29212927   have a self-defined message length (i.e., one not defined by closure
    29222928   of the connection), as described in <xref target="message.body"/>.
     
    29682974</t>
    29692975<t>
    2970    An automatic retry &SHOULD-NOT; be repeated if it fails.
     2976   A client &SHOULD-NOT; automatically retry a failed automatic retry.
    29712977</t>
    29722978</section>
     
    29832989</t>
    29842990<t>
    2985    A client that pipelines requests &MUST; be prepared to retry those
    2986    requests if the connection closes before it receives all of the
    2987    corresponding responses. A client that assumes a persistent connection and
    2988    pipelines immediately after connection establishment &MUST-NOT; pipeline
    2989    on a retry connection until it knows the connection is persistent.
     2991   A client that pipelines requests &SHOULD; retry unanswered requests if the
     2992   connection closes before it receives all of the corresponding responses.
     2993   When retrying pipelined requests after a failed connection (a connection
     2994   not explicitly closed by the server in its last complete response), a
     2995   client &MUST-NOT; pipeline immediately after connection establishment,
     2996   since the first remaining request in the prior pipeline might have caused
     2997   an error response that can be lost again if multiple requests are sent on a
     2998   prematurely closed connection (see the TCP reset problem described in
     2999   <xref target="persistent.tear-down"/>).
    29903000</t>
    29913001<t>
    29923002   Idempotent methods (&idempotent-methods;) are significant to pipelining
    29933003   because they can be automatically retried after a connection failure.
    2994    A user agent &SHOULD-NOT; pipeline requests after a non-idempotent method
     3004   A user agent &SHOULD-NOT; pipeline requests after a non-idempotent method,
    29953005   until the final response status code for that method has been received,
    29963006   unless the user agent has a means to detect and recover from partial
     
    31633173   &MUST; send an Upgrade header field to indicate the new protocol(s) to
    31643174   which the connection is being switched; if multiple protocol layers are
    3165    being switched, the new protocols &MUST; be listed in layer-ascending
     3175   being switched, the sender &MUST; list the protocols in layer-ascending
    31663176   order. A server &MUST-NOT; switch to a protocol that was not indicated by
    31673177   the client in the corresponding request's Upgrade header field.
     
    31933203   use by the server is optional. The capabilities and nature of the
    31943204   application-level communication after the protocol change is entirely
    3195    dependent upon the new protocol(s) chosen, although the first action
    3196    after changing the protocol &MUST; be a response to the initial HTTP
    3197    request that contained the Upgrade header field.
     3205   dependent upon the new protocol(s) chosen. However, immediately after
     3206   sending the 101 response, the server is expected to continue responding to
     3207   the original request as if it had received its equivalent within the new
     3208   protocol (i.e., the server still has an outstanding request to satisfy
     3209   after the protocol has been changed, and is expected to do so without
     3210   requiring the request to be repeated).
    31983211</t>
    31993212<t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2333 r2334  
    16111611      </p>
    16121612      <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would
    1613          be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient <em class="bcp14">SHOULD</em> exclude any request header fields from the response body that are likely to contain sensitive data.
     1613         be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
    16141614      </p>
    16151615      <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
     
    21152115      <div id="rfc.iref.r.2"></div>
    21162116      <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h3>
    2117       <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST</em> exclude any fragment or userinfo components <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> when generating the Referer field value.
     2117      <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST NOT</em> include the fragment and userinfo components of the URI reference <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, if any, when generating the Referer field value.
    21182118      </p>
    21192119      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
     
    24262426         servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    24272427      </p>
    2428       <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect one.
     2428      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx status responses received prior to a final response, even if the client does not expect one.
    24292429         A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
    24302430      </p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2333 r2334  
    17471747   would be foolish for a user agent to send stored user credentials
    17481748   <xref target="Part7"/> or cookies <xref target="RFC6265"/> in a TRACE
    1749    request. The final recipient &SHOULD; exclude any request header fields
    1750    from the response body that are likely to contain sensitive data.
     1749   request. The final recipient of the request &SHOULD; exclude any request
     1750   header fields that are likely to contain sensitive data when that recipient
     1751   generates the response body.
    17511752</t>
    17521753<t>
     
    24812482   reference for the resource from which the <x:ref>target URI</x:ref> was
    24822483   obtained (i.e., the "referrer", though the field name is misspelled).
    2483    A user agent &MUST; exclude any fragment or userinfo components
    2484    <xref target="RFC3986"/> when generating the Referer field value.
     2484   A user agent &MUST-NOT; include the fragment and userinfo components
     2485   of the URI reference <xref target="RFC3986"/>, if any, when generating the
     2486   Referer field value.
    24852487</t>
    24862488<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
     
    27332735</t>
    27342736<t>
    2735    A client &MUST; be prepared to accept one or more 1xx status responses
     2737   A client &MUST; be able to parse one or more 1xx status responses received
    27362738   prior to a final response, even if the client does not expect one.
    27372739   A user agent &MAY; ignore unexpected 1xx status responses.
Note: See TracChangeset for help on using the changeset viewer.