Changeset 1313 for draft-ietf-httpbis


Ignore:
Timestamp:
27/06/11 11:39:35 (11 years ago)
Author:
julian.reschke@…
Message:

make HTTP version numbers single digits (see #273)

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r1267 r1313  
    3030HTTP-Prot-Name = %x48.54.54.50 ; HTTP
    3131
    32 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
     32HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
    3333HTTP-date = rfc1123-date / obs-date
    3434HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ]

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

    r1311 r1313  
    359359  }
    360360  @bottom-center {
    361        content: "Expires December 26, 2011";
     361       content: "Expires December 29, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-06-24">
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-06-27">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: December 26, 2011</td>
     444               <td class="left">Expires: December 29, 2011</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">June 24, 2011</td>
     497               <td class="right">June 27, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    525525         in progress”.
    526526      </p>
    527       <p>This Internet-Draft will expire on December 26, 2011.</p>
     527      <p>This Internet-Draft will expire on December 29, 2011.</p>
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    10191019      </p>
    10201020      <p id="rfc.section.2.5.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    1021       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
     1021      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
    10221022  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    1023 </pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two non-negative decimal integers separated by a "." (period or decimal point). The first
    1024          number ("major version") indicates the HTTP messaging syntax, whereas the second number ("minor version") indicates the highest
    1025          minor version to which the sender is at least conditionally compliant and able to understand for future communication. The
    1026          minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible
    1027          subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers)
    1028          or in future requests (by clients).
    1029       </p>
    1030       <p id="rfc.section.2.5.p.5">When comparing HTTP versions, the numbers <em class="bcp14">MUST</em> be compared numerically rather than lexically. For example, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower
    1031          than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.
    1032       </p>
    1033       <p id="rfc.section.2.5.p.6">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
     1023</pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
     1024         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
     1025         to which the sender is at least conditionally compliant and able to understand for future communication. The minor version
     1026         advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the
     1027         protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future
     1028         requests (by clients).
     1029      </p>
     1030      <p id="rfc.section.2.5.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
    10341031         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    10351032         so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt
    10361033         of a message, that the recipient supports HTTP/1.1.
    10371034      </p>
    1038       <p id="rfc.section.2.5.p.7">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default
     1035      <p id="rfc.section.2.5.p.6">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default
    10391036         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    10401037         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by
    10411038         all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1.
    10421039      </p>
    1043       <p id="rfc.section.2.5.p.8">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
     1040      <p id="rfc.section.2.5.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    10441041         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
    10451042         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;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10461043      </p>
    1047       <p id="rfc.section.2.5.p.9">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <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
     1044      <p id="rfc.section.2.5.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <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
    10481045         understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
    10491046         message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
    10501047         sender's version to determine what features are safe to use for later communication with that sender.
    10511048      </p>
    1052       <p id="rfc.section.2.5.p.10">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
     1049      <p id="rfc.section.2.5.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
    10531050         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.
    10541051      </p>
    1055       <p id="rfc.section.2.5.p.11">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
     1052      <p id="rfc.section.2.5.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
    10561053         the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server)
    10571054         that the server improperly handles higher request versions.
    10581055      </p>
    1059       <p id="rfc.section.2.5.p.12">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
     1056      <p id="rfc.section.2.5.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
    10601057         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
    10611058         request.
    10621059      </p>
    1063       <p id="rfc.section.2.5.p.13">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
     1060      <p id="rfc.section.2.5.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
    10641061         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    10651062         number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the
    … …  
    10671064         User-Agent) uniquely match the values sent by a client known to be in error.
    10681065      </p>
    1069       <p id="rfc.section.2.5.p.14">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
     1066      <p id="rfc.section.2.5.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    10701067         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    10711068         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    … …  
    30523049         and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    30533050      </p>
    3054       <p id="rfc.section.B.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABNF production is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>)
     3051      <p id="rfc.section.B.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single
     3052         digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>)
    30553053      </p>
    30563054      <p id="rfc.section.B.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    … …  
    30873085
    30883086<a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; HTTP
    3089 <a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
     3087<a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" DIGIT "." DIGIT
    30903088<a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date
    30913089<a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [ message-body
    … …  
    35793577      </ul>
    35803578      <h2 id="rfc.section.D.16"><a href="#rfc.section.D.16">D.16</a>&nbsp;<a id="changes.since.14" href="#changes.since.14">Since draft-ietf-httpbis-p1-messaging-14</a></h2>
    3581       <p id="rfc.section.D.16.p.1">None yet.</p>
     3579      <p id="rfc.section.D.16.p.1">Closed issues: </p>
     3580      <ul>
     3581         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>&gt;: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT"
     3582         </li>
     3583      </ul>
    35823584      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    35833585      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>

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

    r1311 r1313  
    825825</t>
    826826<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>
    827   <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
     827  <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" <x:ref>DIGIT</x:ref> "." <x:ref>DIGIT</x:ref>
    828828  <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
    829829</artwork></figure>
    830830<t>
    831    The HTTP version number consists of two non-negative decimal integers
    832    separated by a "." (period or decimal point).  The first
    833    number ("major version") indicates the HTTP messaging syntax, whereas
    834    the second number ("minor version") indicates the highest minor
    835    version to which the sender is at least conditionally compliant and
    836    able to understand for future communication.  The minor version
    837    advertises the sender's communication capabilities even when the
     831   The HTTP version number consists of two decimal digits separated by a "."
     832   (period or decimal point).  The first digit ("major version") indicates the
     833   HTTP messaging syntax, whereas the second digit ("minor version") indicates
     834   the highest minor version to which the sender is at least conditionally
     835   compliant and able to understand for future communication.  The minor
     836   version advertises the sender's communication capabilities even when the
    838837   sender is only using a backwards-compatible subset of the protocol,
    839838   thereby letting the recipient know that more advanced features can
    840839   be used in response (by servers) or in future requests (by clients).
    841 </t>
    842 <t>
    843    When comparing HTTP versions, the numbers &MUST; be compared
    844    numerically rather than lexically.  For example, HTTP/2.4 is a lower
    845    version than HTTP/2.13, which in turn is lower than HTTP/12.3.
    846    Leading zeros &MUST; be ignored by recipients and &MUST-NOT; be sent.
    847840</t>
    848841<t>
    … …  
    50115004</t>
    50125005<t>
    5013   Clarify that the string "HTTP" in the HTTP-Version ABNF production is case
    5014   sensitive.
     5006  Clarify that the string "HTTP" in the HTTP-Version ABFN production is case
     5007  sensitive. Restrict the version numbers to be single digits due to the fact
     5008  that implementations are known to handle multi-digit version numbers
     5009  incorrectly.
    50155010  (<xref target="http.version"/>)
    50165011</t>
    … …  
    50765071
    50775072<x:ref>HTTP-Prot-Name</x:ref> = %x48.54.54.50 ; HTTP
    5078 <x:ref>HTTP-Version</x:ref> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
     5073<x:ref>HTTP-Version</x:ref> = HTTP-Prot-Name "/" DIGIT "." DIGIT
    50795074<x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date
    50805075<x:ref>HTTP-message</x:ref> = start-line *( header-field CRLF ) CRLF [ message-body
    … …  
    58955890<section title="Since draft-ietf-httpbis-p1-messaging-14" anchor="changes.since.14">
    58965891<t>
    5897   None yet.
     5892  Closed issues:
     5893  <list style="symbols">
     5894    <t>
     5895      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/273"/>:
     5896      "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT"
     5897    </t>
     5898  </list>
    58985899</t>
    58995900</section>
Note: See TracChangeset for help on using the changeset viewer.