Ignore:
Timestamp:
Jan 29, 2012, 7:09:15 PM (8 years ago)
Author:
fielding@…
Message:

Remove conditional compliance. Switch from compliance to conformance.

File:
1 edited

Legend:

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

    r1519 r1520  
    892892         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    893893         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    894          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
     894         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
    895895      </p>
    896896      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
     
    951951      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    952952      <p id="rfc.section.2.6.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
    953          The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's
     953         The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's
    954954         corresponding specification of HTTP.
    955955      </p>
     
    959959</pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
    960960         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    961          to which the sender is at least conditionally compliant and able to understand for future communication. The minor version
    962          advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the
    963          protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future
    964          requests (by clients).
     961         to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's
     962         communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting
     963         the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
    965964      </p>
    966965      <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
    967966         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    968          so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt
     967         so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt
    969968         of a message, that the recipient supports HTTP/1.1.
    970969      </p>
     
    972971         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    973972         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by
    974          all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1.
     973         all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
    975974      </p>
    976975      <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
    977976         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
    978          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    979       </p>
    980       <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 matches what the intermediary
    981          understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
    982          message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
    983          sender's version to determine what features are safe to use for later communication with that sender.
    984       </p>
    985       <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major
    986          version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant.
     977         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
     978      </p>
     979      <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
     980         to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without
     981         rewriting the HTTP-Version might result in communication errors when downstream recipients use the message sender's version
     982         to determine what features are safe to use for later communication with that sender.
     983      </p>
     984      <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
     985         than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
    987986      </p>
    988987      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
     
    990989         that the server improperly handles higher request versions.
    991990      </p>
    992       <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major
    993          version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
     991      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
     992         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
    994993         request.
    995994      </p>
    996995      <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
    997996         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    998          number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the
     997         number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't conform to the
    999998         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g.,
    1000999         User-Agent) uniquely match the values sent by a client known to be in error.
     
    16591658      </ol>
    16601659      <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    1661          forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly
     1660         forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly
    16621661         infinite buffer on the proxy.
    16631662      </p>
     
    20612060         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
    20622061         if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially
    2063          compliant.
     2062         conformant.
    20642063      </p>
    20652064      <p id="rfc.section.8.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
     
    29052904      <p id="rfc.section.A.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding
    29062905         only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a
    2907          party advertising compliance with HTTP/1.1.
    2908       </p>
    2909       <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately
     2906         party advertising conformance with HTTP/1.1.
     2907      </p>
     2908      <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate conformance with previous versions. HTTP/1.1 was deliberately
    29102909         designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
    29112910         any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood
Note: See TracChangeset for help on using the changeset viewer.