Changeset 1313 for draft-ietf-httpbis
- Timestamp:
- 27/06/11 11:39:35 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/httpbis.abnf
r1267 r1313 30 30 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 31 31 32 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT32 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 33 33 HTTP-date = rfc1123-date / obs-date 34 34 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ] -
draft-ietf-httpbis/latest/p1-messaging.html
r1311 r1313 359 359 } 360 360 @bottom-center { 361 content: "Expires December 2 6, 2011";361 content: "Expires December 29, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-06-2 4">412 <meta name="dct.issued" scheme="ISO8601" content="2011-06-27"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: December 2 6, 2011</td>444 <td class="left">Expires: December 29, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">June 2 4, 2011</td>497 <td class="right">June 27, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on December 2 6, 2011.</p>527 <p>This Internet-Draft will expire on December 29, 2011.</p> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1019 1019 </p> 1020 1020 <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> 1022 1022 <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 1034 1031 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 1035 1032 so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt 1036 1033 of a message, that the recipient supports HTTP/1.1. 1037 1034 </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 default1035 <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 1039 1036 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 1040 1037 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by 1041 1038 all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1. 1042 1039 </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 interpretation1040 <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 1044 1041 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 1045 1042 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 9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1046 1043 </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 intermediary1044 <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 1048 1045 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 1049 1046 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message 1050 1047 sender's version to determine what features are safe to use for later communication with that sender. 1051 1048 </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 major1049 <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 1053 1050 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. 1054 1051 </p> 1055 <p id="rfc.section.2.5.p.1 1">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 after1052 <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 1056 1053 the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) 1057 1054 that the server improperly handles higher request versions. 1058 1055 </p> 1059 <p id="rfc.section.2.5.p.1 2">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 major1056 <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 1060 1057 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 1061 1058 request. 1062 1059 </p> 1063 <p id="rfc.section.2.5.p.1 3">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 HTTP1060 <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 1064 1061 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1065 1062 number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the … … 1067 1064 User-Agent) uniquely match the values sent by a client known to be in error. 1068 1065 </p> 1069 <p id="rfc.section.2.5.p.1 4">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax1066 <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 1070 1067 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1071 1068 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented … … 3052 3049 and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 3053 3050 </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 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 2.5</a>) 3055 3053 </p> 3056 3054 <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 3.2</a>) … … 3087 3085 3088 3086 <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*DIGIT3087 <a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" DIGIT "." DIGIT 3090 3088 <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date 3091 3089 <a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [ message-body … … 3579 3577 </ul> 3580 3578 <h2 id="rfc.section.D.16"><a href="#rfc.section.D.16">D.16</a> <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> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>>: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" 3582 </li> 3583 </ul> 3582 3584 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 3583 3585 <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 825 825 </t> 826 826 <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> 828 828 <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive 829 829 </artwork></figure> 830 830 <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 838 837 sender is only using a backwards-compatible subset of the protocol, 839 838 thereby letting the recipient know that more advanced features can 840 839 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 compared844 numerically rather than lexically. For example, HTTP/2.4 is a lower845 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.847 840 </t> 848 841 <t> … … 5011 5004 </t> 5012 5005 <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. 5015 5010 (<xref target="http.version"/>) 5016 5011 </t> … … 5076 5071 5077 5072 <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*DIGIT5073 <x:ref>HTTP-Version</x:ref> = HTTP-Prot-Name "/" DIGIT "." DIGIT 5079 5074 <x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date 5080 5075 <x:ref>HTTP-message</x:ref> = start-line *( header-field CRLF ) CRLF [ message-body … … 5895 5890 <section title="Since draft-ietf-httpbis-p1-messaging-14" anchor="changes.since.14"> 5896 5891 <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> 5898 5899 </t> 5899 5900 </section>
Note: See TracChangeset
for help on using the changeset viewer.