Changeset 928 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

24/07/10 14:06:46 (12 years ago)

Author:

julian.reschke@…

Message:

regen HTML

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (9 diffs)

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

@@ -875 +875 @@
       </p>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2>
-      <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response.</p>
+      <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status-Line of an HTTP response.</p>
       <p id="rfc.section.4.1.p.2">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
       </p>
@@ -917 +917 @@
             at the Effective Request URI.
          </li>
-         <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
+         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
             of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
          </li>
@@ -1033 +1033 @@
       </p>
       <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
-         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes a representation
-         that describes the result.
+         200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
+         representation that describes the result.
       </p>
       <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
@@ -1057 +1057 @@
       <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
       </p>
-      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request is a success status. Responses to the PUT method are not cacheable.
+      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
       </p>
       <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
@@ -1197 +1197 @@
       <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body.
          The resource metadata and representation metadata in the response message's header fields refer to the requested resource
-         and its current representation, respectively, after the requested action. For example, if a 204 status is received in response
-         to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation
-         that was successfully PUT to the requested resource.
+         and its current representation, respectively, after the requested action. For example, if a 204 status code is received in
+         response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for
+         the representation that was successfully PUT to the requested resource.
       </p>
       <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input
@@ -1288 +1288 @@
          resource.
       </p>
-      <p id="rfc.section.8.3.4.p.2">The 303 status is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect
-         the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form
-         that can be separately identified, bookmarked, and cached independent of the original request.
+      <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action
+         to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response
+         in a form that can be separately identified, bookmarked, and cached independent of the original request.
       </p>
       <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
@@ -1309 +1309 @@
       <div id="rfc.iref.s.16"></div>
       <h3 id="rfc.section.8.3.6"><a href="#rfc.section.8.3.6">8.3.6</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
-      <p id="rfc.section.8.3.6.p.1">The 305 status was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;A</a>), and is now deprecated.
+      <p id="rfc.section.8.3.6.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;A</a>), and is now deprecated.
       </p>
       <div id="rfc.iref.40"></div>
@@ -1321 +1321 @@
       </p>
       <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
-         the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
+         the 307 status code. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
       </p>
       <p id="rfc.section.8.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
@@ -1551 +1551 @@
                            *<a href="#header.expect" class="smpl">expect-params</a> ]
   <a href="#header.expect" class="smpl">expect-params</a> = ";" <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
-</pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with
-         the request, some other 4xx status.
+</pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status code. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code if any of the expectations cannot be met or, if there are other problems
+         with the request, some other 4xx status code.
       </p>
       <p id="rfc.section.9.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing
-         an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status.
+         an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
       </p>
       <p id="rfc.section.9.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive
          for quoted-string expectation-extensions.
       </p>
-      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect
-         request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
+      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
+         Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
       </p>
       <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
-      <p id="rfc.section.9.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.28"><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.9.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.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
       </p>
       <div id="rfc.iref.f.1"></div>