Ignore:
Timestamp:
03/06/13 06:24:51 (10 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

Location:
draft-ietf-httpbis/latest
Files:
4 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>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2276 r2277  
    668668   (period or decimal point).  The first digit ("major version") indicates the
    669669   HTTP messaging syntax, whereas the second digit ("minor version") indicates
    670    the highest minor version to which the sender is
     670   the highest minor version within that major version to which the sender is
    671671   conformant and able to understand for future communication.  The minor
    672672   version advertises the sender's communication capabilities even when the
    … …  
    721721</t>
    722722<t>
    723    An HTTP client &SHOULD; send a request version equal to the highest
     723   A client &SHOULD; send a request version equal to the highest
    724724   version to which the client is conformant and
    725725   whose major version is no higher than the highest version supported
    726    by the server, if this is known.  An HTTP client &MUST-NOT; send a
     726   by the server, if this is known.  A client &MUST-NOT; send a
    727727   version to which it is not conformant.
    728728</t>
    729729<t>
    730    An HTTP client &MAY; send a lower request version if it is known that
     730   A client &MAY; send a lower request version if it is known that
    731731   the server incorrectly implements the HTTP specification, but only
    732732   after the client has attempted at least one normal request and determined
    … …  
    735735</t>
    736736<t>
    737    An HTTP server &SHOULD; send a response version equal to the highest
     737   A server &SHOULD; send a response version equal to the highest
    738738   version to which the server is conformant and
    739739   whose major version is less than or equal to the one received in the
    740    request.  An HTTP server &MUST-NOT; send a version to which it is not
     740   request.  A server &MUST-NOT; send a version to which it is not
    741741   conformant.  A server &MAY; send a <x:ref>505 (HTTP Version Not
    742742   Supported)</x:ref> response if it cannot send a response using the
    … …  
    744744</t>
    745745<t>
    746    An HTTP server &MAY; send an HTTP/1.0 response to an HTTP/1.0 request
     746   A server &MAY; send an HTTP/1.0 response to a request
    747747   if it is known or suspected that the client incorrectly implements the
    748748   HTTP specification and is incapable of correctly processing later
    … …  
    764764   <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
    765765   has specifically avoided any such changes to the protocol.
     766</t>
     767<t>
     768   When an HTTP message is received with a major version number that the
     769   recipient implements, but a higher minor version number than what the
     770   recipient implements, the recipient &SHOULD; process the message as if it
     771   were in the highest minor version within that major version to which the
     772   recipient is conformant. A recipient can assume that a message with a
     773   higher minor version, when sent to a recipient that has not yet indicated
     774   support for that higher version, is sufficiently backwards-compatible to be
     775   safely processed by any implementation of the same major version.
    766776</t>
    767777</section>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2273 r2277  
    449449  }
    450450  @bottom-center {
    451        content: "Expires November 25, 2013";
     451       content: "Expires November 2013";
    452452  }
    453453  @bottom-right {
    … …  
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-05-24">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-05">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">May 24, 2013</td>
     524               <td class="right">May 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: November 25, 2013</td>
     527               <td class="left">Expires: November 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on November 25, 2013.</p>
     555      <p>This Internet-Draft will expire in November 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    28152815      <div id="rfc.iref.77"></div>
    28162816      <h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
    2817       <p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the protocol version that was used in the request
    2818          message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the
    2819          client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are
     2817      <p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in
     2818         the request message. The server is indicating that it is unable or unwilling to complete the request using the same major
     2819         version as the client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are
    28202820         supported by that server.
    28212821      </p>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2256 r2277  
    36013601<t>
    36023602   The <x:dfn>505 (HTTP Version Not Supported)</x:dfn> status code indicates
    3603    that the server does not support, or refuses to support, the protocol
    3604    version that was used in the request message. The server is indicating that
     3603   that the server does not support, or refuses to support, the major version
     3604   of HTTP that was used in the request message. The server is indicating that
    36053605   it is unable or unwilling to complete the request using the same major
    36063606   version as the client, as described in &http-version;, other than with this
Note: See TracChangeset for help on using the changeset viewer.