Changeset 137

Timestamp:

Jan 3, 2008, 8:21:04 AM (12 years ago)

Author:

julian.reschke@…

Message:

Use consistent status reason phrases.

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (3 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (1 diff)
• p3-payload.html (modified) (2 diffs)
• p3-payload.xml (modified) (2 diffs)
• p4-conditional.html (modified) (1 diff)
• p4-conditional.xml (modified) (1 diff)
• p5-range.html (modified) (3 diffs)
• p5-range.xml (modified) (3 diffs)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)

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

@@ -1108 +1108 @@
       <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
       </p>
-      <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Unimplemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
+      <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
       </p>
       <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3>
@@ -1230 +1230 @@
       <p id="rfc.section.4.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
          the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;6.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational),
-         204 (no content), and 304 (not modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.
+         204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.
       </p>
       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="message.length" href="#message.length">Message Length</a></h2>
@@ -1271 +1271 @@
       </ol>
       <p id="rfc.section.4.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body
-         and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes
+         and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 (Bad Request) if it cannot determine the length of the message, or with 411 (Length Required) if it wishes
          to insist on receiving a valid Content-Length.
       </p>

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

@@ -1205 +1205 @@
 <t>
    A server which receives an entity-body with a transfer-coding it does
-   not understand &SHOULD; return 501 (Unimplemented), and close the
+   not understand &SHOULD; return 501 (Not Implemented), and close the
    connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
    client.
@@ -1433 +1433 @@
    &MUST-NOT; include a message-body, even though the presence of entity-header
    fields might lead one to believe they do. All 1xx
-   (informational), 204 (no content), and 304 (not modified) responses
+   (informational), 204 (No Content), and 304 (Not Modified) responses
    &MUST-NOT; include a message-body. All other responses do include a
    message-body, although it &MAY; be of zero length.
@@ -1498 +1498 @@
    field unless the server is known to be HTTP/1.1 compliant. If a
    request contains a message-body and a Content-Length is not given,
-   the server &SHOULD; respond with 400 (bad request) if it cannot
-   determine the length of the message, or with 411 (length required) if
+   the server &SHOULD; respond with 400 (Bad Request) if it cannot
+   determine the length of the message, or with 411 (Length Required) if
    it wishes to insist on receiving a valid Content-Length.
 </t>

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1388 +1388 @@
       </p>
       <p id="rfc.section.10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
-      <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (continue) status.
+      <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
       </p>
       <div id="rfc.iref.f.1"></div>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1725 +1725 @@
 </t>
 <t>
-   See &use100; for the use of the 100 (continue) status.
+   See &use100; for the use of the 100 (Continue) status.
 </t>
 </section>

draft-ietf-httpbis/latest/p3-payload.html

@@ -912 +912 @@
       <p id="rfc.section.5.1.p.8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
          is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
-         the server <em class="bcp14">SHOULD</em> send a 406 (not acceptable) response.
+         the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
       </p>
       <p id="rfc.section.5.1.p.9">A more elaborate example is</p>
@@ -963 +963 @@
       </p>
       <p id="rfc.section.5.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
-         present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.
+         present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
       </p>
       <div id="rfc.iref.a.3"></div>

draft-ietf-httpbis/latest/p3-payload.xml

@@ -886 +886 @@
    and if the server cannot send a response which is acceptable
    according to the combined Accept field value, then the server &SHOULD;
-   send a 406 (not acceptable) response.
+   send a 406 (Not Acceptable) response.
 </t>
 <t>
@@ -981 +981 @@
    and if the server cannot send a response which is acceptable
    according to the Accept-Charset header, then the server &SHOULD; send
-   an error response with the 406 (not acceptable) status code, though
+   an error response with the 406 (Not Acceptable) status code, though
    the sending of an unacceptable response is also allowed.
 </t>

draft-ietf-httpbis/latest/p4-conditional.html

@@ -772 +772 @@
       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
       <p id="rfc.section.6.3.p.1">The If-Modified-Since request-header field is used with a method to make it conditional: if the requested variant has not
-         been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not
-         modified) response will be returned without any message-body.
+         been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not
+         Modified) response will be returned without any message-body.
       </p>
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  If-Modified-Since = "If-Modified-Since" ":" HTTP-date

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -671 +671 @@
    make it conditional: if the requested variant has not been modified
    since the time specified in this field, an entity will not be
-   returned from the server; instead, a 304 (not modified) response will
+   returned from the server; instead, a 304 (Not Modified) response will
    be returned without any message-body.
 </t>

draft-ietf-httpbis/latest/p5-range.html

@@ -566 +566 @@
       <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Byte Ranges">4</a>.
       </p>
-      <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial) responses.
+      <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses.
       </p>
       <div id="rfc.iref.4"></div>
@@ -659 +659 @@
          a Content-Length header showing the number of bytes actually transferred. For example,
       </p>
-      <div id="rfc.figure.u.10"></div><pre class="text">    HTTP/1.1 206 Partial content
+      <div id="rfc.figure.u.10"></div><pre class="text">    HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 1995 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
@@ -700 +700 @@
          no more than two characters.) The If-Range header <em class="bcp14">SHOULD</em> only be used together with a Range header, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
       </p>
-      <p id="rfc.section.5.3.p.5">If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the entity using a 206 (Partial content) response. If the entity tag does not match, then
+      <p id="rfc.section.5.3.p.5">If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the entity using a 206 (Partial Content) response. If the entity tag does not match, then
          the server <em class="bcp14">SHOULD</em> return the entire entity using a 200 (OK) response.
       </p>

draft-ietf-httpbis/latest/p5-range.xml

@@ -293 +293 @@
 <t>
    A cache that does not support the Range and Content-Range headers
-   &MUST-NOT; cache 206 (Partial) responses.
+   &MUST-NOT; cache 206 (Partial Content) responses.
 </t>
 </section>
@@ -474 +474 @@
 </t>
 <figure><artwork type="example">
-    HTTP/1.1 206 Partial content
+    HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 1995 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
@@ -556 +556 @@
    If the entity tag given in the If-Range header matches the current
    entity tag for the entity, then the server &SHOULD; provide the
-   specified sub-range of the entity using a 206 (Partial content)
+   specified sub-range of the entity using a 206 (Partial Content)
    response. If the entity tag does not match, then the server &SHOULD;
    return the entire entity using a 200 (OK) response.

draft-ietf-httpbis/latest/p6-cache.html

@@ -698 +698 @@
             see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a>).
          </li>
-         <li>It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or error (4xx or 5xx) response message.</li>
+         <li>It is an appropriate 304 (Not Modified), 305 (Use Proxy), or error (4xx or 5xx) response message.</li>
       </ol>
       <p id="rfc.section.2.1.1.p.2">If the cache can not communicate with the origin server, then a correct cache <em class="bcp14">SHOULD</em> respond as above if the response can be correctly served from the cache; if not it <em class="bcp14">MUST</em> return an error or warning indicating that there was a communication failure.

draft-ietf-httpbis/latest/p6-cache.xml

@@ -471 +471 @@
          "no-cache" cache-request-directive; see <xref target="header.cache-control"/>).</t>
 
-      <t>It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+      <t>It is an appropriate 304 (Not Modified), 305 (Use Proxy),
          or error (4xx or 5xx) response message.</t>
   </list>