Changeset 920 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

Jul 24, 2010, 6:43:06 AM (9 years ago)

Author:

ylafon@…

Message:

generated after [919] (see #234)

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (9 diffs)

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

@@ -392 +392 @@
       <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
       <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.518, 2010-06-27 12:07:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.518, 2010-06-27 12:07:31, XSLT vendor: SAXON 8.9.0.4 from Saxonica http://www.saxonica.com/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <meta name="dct.creator" content="Fielding, R.">
@@ -1255 +1255 @@
             </p>
             <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value,
-               the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status and then close the connection. If this is a response message received by a proxy or
-               gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status as its downstream response, and then close the connection.
+               the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy
+               or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
                If this is a response message received by a user-agent, the message-body length is determined by reading the connection until
                it is closed; an error <em class="bcp14">SHOULD</em> be indicated to the user.
@@ -1373 +1373 @@
          </p> 
       </div>
-      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
+      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) 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 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
@@ -1775 +1775 @@
       </p>
       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
-         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
+         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
       </p>
       <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
@@ -1881 +1881 @@
       </p>
       <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
-      <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status,
-         it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
+      <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
+         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
       </p>
       <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
-      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
+      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
          to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
          be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
@@ -1898 +1898 @@
       </ul>
       <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
-         100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client
-         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the
-         client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
+         100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
+         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
+         the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
       </p>
       <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
       <ul>
-         <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code.
-            The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
+         <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
+            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
          </li>
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
             expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
-            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
+            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
             field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
-            associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
-            any other HTTP-version value.
+            associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests
+            with any other HTTP-version value.
          </li>
          <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
@@ -1932 +1932 @@
             server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
          </li>
-         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status.
+         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
          </li>
          <li>Proxies <em class="bcp14">SHOULD</em> maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers.
@@ -1944 +1944 @@
       <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field
          with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the
-         client sees the connection close before receiving any status from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response: 
+         client sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response: 
       </p>
       <ol>
@@ -1959 +1959 @@
          </li>
       </ol>
-      <p id="rfc.section.7.2.4.p.2">If at any point an error status is received, the client </p>
+      <p id="rfc.section.7.2.4.p.2">If at any point an error status code is received, the client </p>
       <ul>
          <li><em class="bcp14">SHOULD NOT</em> continue and