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

Timestamp:

04/07/12 19:22:01 (10 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (3xx range)

File:

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

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

@@ -1030 +1030 @@
       <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
       </p>
-      <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
-         to retrieve a cacheable representation of the resource.
+      <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
       </p>
       <div id="rfc.iref.p.2"></div>
@@ -1077 +1076 @@
          is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
          the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
-         to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
+         to a different URI, then the origin server <em class="bcp14">MUST</em> send a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
       </p>
       <p id="rfc.section.2.3.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)
@@ -1771 +1770 @@
          <li>
             <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header
-               field. In this specification, the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect) fall under
-               this category.
+               field. In this specification, the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.
             </p>
          </li>
          <li>
             <p>Redirection to a new location that represents an indirect response to the request, such as the result of a POST operation
-               to be retrieved with a subsequent GET request. This is status code 303 (See Other).
+               to be retrieved with a subsequent GET request. This is status code <a href="#status.303" class="smpl">303 (See
+                  Other)</a>.
             </p>
          </li>
          <li>
-            <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Section&nbsp;8.2</a>). This is status code 300 (Multiple Choices).
+            <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Section&nbsp;8.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
             </p>
          </li>
@@ -1791 +1790 @@
       </ol>
       <div class="note" id="rfc.section.4.5.p.3"> 
-         <p> <b>Note:</b> In HTTP/1.0, only the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect, and
-            the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to
-            retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code 303 (See Other)
-            (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
-            yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification
+         <p> <b>Note:</b> In HTTP/1.0, only the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect, and the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to
+            retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
+            yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification
             makes that behavior conformant in case the original request was POST.
          </p> 
@@ -1837 +1834 @@
       </p>
       <div class="note" id="rfc.section.4.5.2.p.4"> 
-         <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary
-            Redirect) can be used instead.
+         <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> can be used instead.
          </p> 
       </div>
@@ -1850 +1846 @@
       </p>
       <div class="note" id="rfc.section.4.5.3.p.3"> 
-         <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary
-            Redirect) can be used instead.
+         <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> can be used instead.
          </p> 
       </div>
@@ -1893 +1888 @@
       </p>
       <div class="note" id="rfc.section.4.5.7.p.3"> 
-         <p> <b>Note:</b> This status code is similar to 302 Found, except that it does not allow rewriting the request method from POST to GET. This
-            specification defines no equivalent counterpart for 301 Moved Permanently (<a href="#draft-reschke-http-status-308" id="rfc.xref.draft-reschke-http-status-308.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[draft-reschke-http-status-308]</cite></a>, however, defines the status code 308 Permanent Redirect for this purpose).
+         <p> <b>Note:</b> This status code is similar to <a href="#status.302" class="smpl">302 (Found)</a>, except that it does not allow rewriting the request method from POST to GET. This specification defines no equivalent counterpart
+            for <a href="#status.301" class="smpl">301 (Moved
+               Permanently)</a> (<a href="#draft-reschke-http-status-308" id="rfc.xref.draft-reschke-http-status-308.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[draft-reschke-http-status-308]</cite></a>, however, defines the status code 308 (Permanent Redirect) for this purpose).
          </p> 
       </div>
@@ -2565 +2561 @@
          and used within HTTP/1.1.
       </p>
-      <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
+      <p id="rfc.section.8.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
          server-driven negotiation.
       </p>