Ignore:
Timestamp:
03/06/13 06:24:51 (7 years ago)
Author:
fielding@…
Message:

Clarify that a recipient SHOULD process received messages in higher minor versions as if they were the highest minor version to wwhich the recipient is conformant; Clarify that 505 is for major version rejection; addresses #449

File:
1 edited

Legend:

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

    r2276 r2277  
    449449  }
    450450  @bottom-center {
    451        content: "Expires November 27, 2013";
     451       content: "Expires November 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-05-26">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-05">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">May 26, 2013</td>
     522               <td class="right">May 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: November 27, 2013</td>
     525               <td class="left">Expires: November 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on November 27, 2013.</p>
     553      <p>This Internet-Draft will expire in November 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    972972</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
    973973         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    974          to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's
    975          communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting
    976          the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
     974         within that major version to which the sender is conformant and able to understand for future communication. The minor version
     975         advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the
     976         protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future
     977         requests (by clients).
    977978      </p>
    978979      <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
     
    994995         to determine what features are safe to use for later communication with that sender.
    995996      </p>
    996       <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
    997          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.
    998       </p>
    999       <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
     997      <p id="rfc.section.2.6.p.9">A 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
     998         than the highest version supported by the server, if this is known. A client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
     999      </p>
     1000      <p id="rfc.section.2.6.p.10">A 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
    10001001         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10011002      </p>
    1002       <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
    1003          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 <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not
     1003      <p id="rfc.section.2.6.p.11">A 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
     1004         or equal to the one received in the request. A 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 <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not
    10041005            Supported)</a> response if it cannot send a response using the major version used in the client's request.
    10051006      </p>
    1006       <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
    1007          specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    1008          number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the
    1009          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., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
     1007      <p id="rfc.section.2.6.p.12">A server <em class="bcp14">MAY</em> send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification
     1008         and is incapable of correctly processing later version responses, such as when a client fails to parse the version number
     1009         correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor
     1010         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., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    10101011      </p>
    10111012      <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
     
    10131014         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    10141015         for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoided any such changes to the protocol.
     1016      </p>
     1017      <p id="rfc.section.2.6.p.14">When an HTTP message is received with a major version number that the recipient implements, but a higher minor version number
     1018         than what the recipient implements, the recipient <em class="bcp14">SHOULD</em> process the message as if it were in the highest minor version within that major version to which the recipient is conformant.
     1019         A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support
     1020         for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major
     1021         version.
    10151022      </p>
    10161023      <div id="rfc.iref.r.5"></div>
Note: See TracChangeset for help on using the changeset viewer.