* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1313


Ignore:
Timestamp:
2011-06-27 04:39:35 (3 years ago)
Author:
julian.reschke@gmx.de
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.