Changeset 1747 for draft-ietf-httpbis

Timestamp:

09/07/12 08:35:28 (9 years ago)

Author:

fielding@…

Message:

fix [1682] so that it takes roles into consideration (#361)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (10 diffs)
• p1-messaging.xml (modified) (5 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 9, 2013"; 
+       content: "Expires January 10, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-09">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -523 +523 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 9, 2013</td>
+               <td class="left">Expires: January 10, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 8, 2012</td>
+               <td class="right">July 9, 2012</td>
             </tr>
          </tbody>
@@ -561 +561 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 9, 2013.</p>
+      <p>This Internet-Draft will expire on January 10, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <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
          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
-         or caches, depending on what behavior is being constrained by the requirement.
+         or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send"
+         where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.
       </p>
       <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
          in HTTP.
       </p>
-      <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.
-      </p>
-      <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
+      <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
+         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
+         to the recipient's role.
+      </p>
+      <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
          except when they have a direct impact on security, since different applications of the protocol require different error handling
          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>
       <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>
-</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 an
+</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
          attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
          result in a security vulnerability if other implementations within the request chain interpret the same message differently.
@@ -1155 +1158 @@
       </p>
       <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>
-</pre><div id="rfc.iref.m.2"></div>
+</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.
+      </p>
+      <div id="rfc.iref.m.2"></div>
       <div id="method">
-         <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>
+         <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>
       </div>
       <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>
-</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.
+</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.
       </p>
       <div id="rfc.iref.r.6"></div>
-      <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&nbsp;5.3</a>.
-      </p>
-      <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-line
+      <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&nbsp;5.3</a>.
+      </p>
+      <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
          into its component parts by splitting on the SP characters.
       </p>
-      <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 characters
+      <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
          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
          crafted to bypass security filters along the request chain.
       </p>
-      <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 that
+      <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
          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>).
       </p>
-      <p id="rfc.section.3.1.1.p.10">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.
+      <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.
       </p>
       <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status.line" href="#status.line">Status Line</a></h3>
@@ -1182 +1187 @@
       </p>
       <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>
-</pre><div id="status-code">
-         <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
+</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.
+      </p>
+      <div id="status-code">
+         <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
             for new status codes.
          </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>
 </pre><div id="reason-phrase">
-         <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 status
+         <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
             code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
             clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
@@ -1372 +1379 @@
       </p>
       <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
-         status code (<a href="#status-code">Paragraph&nbsp;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>.)
+         status code (<a href="#status-code">Paragraph&nbsp;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>.)
       </p>
       <div id="rfc.iref.t.4"></div>

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

@@ -600 +600 @@
    on senders, recipients, clients, servers, user agents, intermediaries,
    origin servers, proxies, gateways, or caches, depending on what behavior
-   is being constrained by the requirement.
+   is being constrained by the requirement. The verb "generate" is used
+   instead of "send" where a requirement differentiates between creating a
+   protocol element and merely forwarding a received element downstream.
 </t>
 <t>
@@ -607 +609 @@
 </t>
 <t>
-   Senders &MUST-NOT; generate protocol elements that do not match the grammar
-   defined by the ABNF rules for those protocol elements.
-</t>
-<t>
-   Unless noted otherwise, recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable
+   A sender &MUST-NOT; generate protocol elements that do not match
+   the grammar defined by the ABNF rules for those protocol elements that
+   are applicable to the sender's role.
+   If a received protocol element is processed, the recipient &MUST; be able
+   to parse any value that would match the ABNF rules for that protocol
+   element, excluding only those rules not applicable to the recipient's role.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    protocol element from an invalid construct.  HTTP does not define
    specific error handling mechanisms except when they have a direct impact
@@ -1019 +1024 @@
 </artwork></figure>
 <t>
-</t>
-<t>
    Implementations &MUST-NOT; send whitespace between the start-line and
    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>
 </artwork></figure>
+<t>
+   A server &MUST; be able to parse any received message that begins
+   with a request-line and matches the ABNF rule for HTTP-message.
+</t>
 <iref primary="true" item="method"/>
 <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>
 </artwork></figure>
+<t>
+   A client &MUST; be able to parse any received message that begins
+   with a status-line and matches the ABNF rule for HTTP-message.
+</t>
 
 <t anchor="status-code">