Changeset 2277 for draft-ietf-httpbis/latest
- Timestamp:
- 03/06/13 06:24:51 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2276 r2277 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2 7, 2013";451 content: "Expires November 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <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"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">May 2 6, 2013</td>522 <td class="right">May 2013</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: November 2 7, 2013</td>525 <td class="left">Expires: November 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on November 27,2013.</p>553 <p>This Internet-Draft will expire in November 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 972 972 </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 973 973 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). 977 978 </p> 978 979 <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 … … 994 995 to determine what features are safe to use for later communication with that sender. 995 996 </p> 996 <p id="rfc.section.2.6.p.9">A n HTTPclient <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 higher997 than the highest version supported by the server, if this is known. A n HTTPclient <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">A n HTTPclient <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after997 <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 1000 1001 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. 1001 1002 </p> 1002 <p id="rfc.section.2.6.p.11">A n HTTPserver <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 than1003 or equal to the one received in the request. A n HTTPserver <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 Not1003 <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 1004 1005 Supported)</a> response if it cannot send a response using the major version used in the client's request. 1005 1006 </p> 1006 <p id="rfc.section.2.6.p.12">A n 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 HTTP1007 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version1008 number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the1009 given minorversion 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. 1010 1011 </p> 1011 1012 <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 … … 1013 1014 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented 1014 1015 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. 1015 1022 </p> 1016 1023 <div id="rfc.iref.r.5"></div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2276 r2277 668 668 (period or decimal point). The first digit ("major version") indicates the 669 669 HTTP messaging syntax, whereas the second digit ("minor version") indicates 670 the highest minor version to which the sender is670 the highest minor version within that major version to which the sender is 671 671 conformant and able to understand for future communication. The minor 672 672 version advertises the sender's communication capabilities even when the … … 721 721 </t> 722 722 <t> 723 A n HTTPclient &SHOULD; send a request version equal to the highest723 A client &SHOULD; send a request version equal to the highest 724 724 version to which the client is conformant and 725 725 whose major version is no higher than the highest version supported 726 by the server, if this is known. A n HTTPclient &MUST-NOT; send a726 by the server, if this is known. A client &MUST-NOT; send a 727 727 version to which it is not conformant. 728 728 </t> 729 729 <t> 730 A n HTTPclient &MAY; send a lower request version if it is known that730 A client &MAY; send a lower request version if it is known that 731 731 the server incorrectly implements the HTTP specification, but only 732 732 after the client has attempted at least one normal request and determined … … 735 735 </t> 736 736 <t> 737 A n HTTPserver &SHOULD; send a response version equal to the highest737 A server &SHOULD; send a response version equal to the highest 738 738 version to which the server is conformant and 739 739 whose major version is less than or equal to the one received in the 740 request. A n HTTPserver &MUST-NOT; send a version to which it is not740 request. A server &MUST-NOT; send a version to which it is not 741 741 conformant. A server &MAY; send a <x:ref>505 (HTTP Version Not 742 742 Supported)</x:ref> response if it cannot send a response using the … … 744 744 </t> 745 745 <t> 746 A n HTTP server &MAY; send an HTTP/1.0 response to an HTTP/1.0request746 A server &MAY; send an HTTP/1.0 response to a request 747 747 if it is known or suspected that the client incorrectly implements the 748 748 HTTP specification and is incapable of correctly processing later … … 764 764 <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision 765 765 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. 766 776 </t> 767 777 </section> -
draft-ietf-httpbis/latest/p2-semantics.html
r2273 r2277 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2 5, 2013";451 content: "Expires November 2013"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <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"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <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."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">May 2 4, 2013</td>524 <td class="right">May 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: November 2 5, 2013</td>527 <td class="left">Expires: November 2013</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on November 25,2013.</p>555 <p>This Internet-Draft will expire in November 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2815 2815 <div id="rfc.iref.77"></div> 2816 2816 <h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a> <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 request2818 message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the2819 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 are2817 <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 2820 2820 supported by that server. 2821 2821 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2256 r2277 3601 3601 <t> 3602 3602 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 protocol3604 versionthat was used in the request message. The server is indicating that3603 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 3605 3605 it is unable or unwilling to complete the request using the same major 3606 3606 version as the client, as described in &http-version;, other than with this
Note: See TracChangeset
for help on using the changeset viewer.