Changeset 1747 for draft-ietf-httpbis
- Timestamp:
- 09/07/12 08:35:28 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1744 r1747 449 449 } 450 450 @bottom-center { 451 content: "Expires January 9, 2013";451 content: "Expires January 10, 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="2012-07-0 8">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-09"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 9, 2013</td>525 <td class="left">Expires: January 10, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 8, 2012</td>530 <td class="right">July 9, 2012</td> 531 531 </tr> 532 532 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on January 9, 2013.</p>563 <p>This Internet-Draft will expire on January 10, 2013.</p> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 953 953 <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 954 954 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 955 or caches, depending on what behavior is being constrained by the requirement. 955 or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send" 956 where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream. 956 957 </p> 957 958 <p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 958 959 in HTTP. 959 960 </p> 960 <p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements. 961 </p> 962 <p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 961 <p id="rfc.section.2.5.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 962 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 963 to the recipient's role. 964 </p> 965 <p id="rfc.section.2.5.p.4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 963 966 except when they have a direct impact on security, since different applications of the protocol require different error handling 964 967 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery … … 1145 1148 </p> 1146 1149 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a> 1147 </pre><p id="rfc.section.3.1.p. 4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an1150 </pre><p id="rfc.section.3.1.p.3">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an 1148 1151 attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might 1149 1152 result in a security vulnerability if other implementations within the request chain interpret the same message differently. … … 1155 1158 </p> 1156 1159 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a> 1157 </pre><div id="rfc.iref.m.2"></div> 1160 </pre><p id="rfc.section.3.1.1.p.3">A server <em class="bcp14">MUST</em> be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message. 1161 </p> 1162 <div id="rfc.iref.m.2"></div> 1158 1163 <div id="method"> 1159 <p id="rfc.section.3.1.1.p. 3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>1164 <p id="rfc.section.3.1.1.p.4">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1160 1165 </div> 1161 1166 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1162 </pre><p id="rfc.section.3.1.1.p. 5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1167 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1163 1168 </p> 1164 1169 <div id="rfc.iref.r.6"></div> 1165 <p id="rfc.section.3.1.1.p. 6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>.1166 </p> 1167 <p id="rfc.section.3.1.1.p. 7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line1170 <p id="rfc.section.3.1.1.p.7">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>. 1171 </p> 1172 <p id="rfc.section.3.1.1.p.8">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line 1168 1173 into its component parts by splitting on the SP characters. 1169 1174 </p> 1170 <p id="rfc.section.3.1.1.p. 8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters1175 <p id="rfc.section.3.1.1.p.9">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters 1171 1176 directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately 1172 1177 crafted to bypass security filters along the request chain. 1173 1178 </p> 1174 <p id="rfc.section.3.1.1.p. 9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that1179 <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1175 1180 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 1176 1181 </p> 1177 <p id="rfc.section.3.1.1.p.1 0">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.1182 <p id="rfc.section.3.1.1.p.11">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. 1178 1183 </p> 1179 1184 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="status.line" href="#status.line">Status Line</a></h3> … … 1182 1187 </p> 1183 1188 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status-code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1184 </pre><div id="status-code"> 1185 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1189 </pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message. 1190 </p> 1191 <div id="status-code"> 1192 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1186 1193 for new status codes. 1187 1194 </p> … … 1189 1196 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status-code" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1190 1197 </pre><div id="reason-phrase"> 1191 <p id="rfc.section.3.1.2.p. 5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status1198 <p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1192 1199 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1193 1200 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. … … 1372 1379 </p> 1373 1380 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1374 status code (<a href="#status-code">Paragraph 3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)1381 status code (<a href="#status-code">Paragraph 4</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.) 1375 1382 </p> 1376 1383 <div id="rfc.iref.t.4"></div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1744 r1747 600 600 on senders, recipients, clients, servers, user agents, intermediaries, 601 601 origin servers, proxies, gateways, or caches, depending on what behavior 602 is being constrained by the requirement. 602 is being constrained by the requirement. The verb "generate" is used 603 instead of "send" where a requirement differentiates between creating a 604 protocol element and merely forwarding a received element downstream. 603 605 </t> 604 606 <t> … … 607 609 </t> 608 610 <t> 609 Senders &MUST-NOT; generate protocol elements that do not match the grammar 610 defined by the ABNF rules for those protocol elements. 611 </t> 612 <t> 613 Unless noted otherwise, recipients &MUST; be able to parse all protocol 614 elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable 611 A sender &MUST-NOT; generate protocol elements that do not match 612 the grammar defined by the ABNF rules for those protocol elements that 613 are applicable to the sender's role. 614 If a received protocol element is processed, the recipient &MUST; be able 615 to parse any value that would match the ABNF rules for that protocol 616 element, excluding only those rules not applicable to the recipient's role. 617 </t> 618 <t> 619 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 615 620 protocol element from an invalid construct. HTTP does not define 616 621 specific error handling mechanisms except when they have a direct impact … … 1019 1024 </artwork></figure> 1020 1025 <t> 1021 </t>1022 <t>1023 1026 Implementations &MUST-NOT; send whitespace between the start-line and 1024 1027 the first header field. The presence of such whitespace in a request … … 1042 1045 <x:ref>request-line</x:ref> = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref> 1043 1046 </artwork></figure> 1047 <t> 1048 A server &MUST; be able to parse any received message that begins 1049 with a request-line and matches the ABNF rule for HTTP-message. 1050 </t> 1044 1051 <iref primary="true" item="method"/> 1045 1052 <t anchor="method"> … … 1105 1112 <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref> 1106 1113 </artwork></figure> 1114 <t> 1115 A client &MUST; be able to parse any received message that begins 1116 with a status-line and matches the ABNF rule for HTTP-message. 1117 </t> 1107 1118 1108 1119 <t anchor="status-code">
Note: See TracChangeset
for help on using the changeset viewer.