Changeset 2087 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

05/01/13 10:21:45 (10 years ago)

Author:

fielding@…

Message:

(editorial) rephrase and consolidate the notes and explanations in 3xx

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (4 diffs)

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

@@ -1128 +1128 @@
 
 <section title="Safe Methods" anchor="safe.methods">
-<iref item="safe" primary="true"/>
-<t>
-   Request methods are considered "<x:dfn anchor="safe">safe</x:dfn>" if
+  <iref item="safe" primary="true"/>
+  <x:anchor-alias value="safe"/>
+<t>
+   Request methods are considered "<x:dfn>safe</x:dfn>" if
    their defined semantics are essentially read-only; i.e., the client does
    not request, and does not expect, any state change on the origin server
@@ -2862 +2863 @@
    The <x:dfn>3xx (Redirection)</x:dfn> class of status code indicates that
    further action needs to be taken by the user agent in order to fulfill the
-   request.
+   request. If a <x:ref>Location</x:ref> header field
+   (<xref target="header.location"/>) is provided, the user agent &MAY;
+   automatically redirect its request to the URI referenced by the Location
+   field value, even if the specific status code is not understood.
+   Automatic redirection needs to done with care for methods not known to be
+   <x:ref>safe</x:ref>, as defined in <xref target="safe.methods"/>, since
+   the user might not wish to redirect an unsafe request.
 </t>
 <t>
@@ -2869 +2876 @@
       <x:lt>
         <t>
-          Redirects of the request to another URI, either temporarily or
-          permanently. The new URI is specified in the <x:ref>Location</x:ref>
-          header field. In this specification, the status codes <x:ref>301
-          (Moved Permanently)</x:ref>, <x:ref>302 (Found)</x:ref>, and
-          <x:ref>307 (Temporary Redirect)</x:ref> fall under this category.
+          Redirects that indicate the resource might be available at a
+          different URI, as provided by the <x:ref>Location</x:ref> field,
+          as in the status codes <x:ref>301 (Moved Permanently)</x:ref>,
+          <x:ref>302 (Found)</x:ref>, and
+          <x:ref>307 (Temporary Redirect)</x:ref>.
         </t>
       </x:lt>
       <x:lt>
         <t>
-          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 <x:ref>303 (See
-          Other)</x:ref>.
+          Redirection that offers a choice of matching resources, each capable
+          of representing the original request target, as in the
+          <x:ref>300 (Multiple Choices)</x:ref> status code.
         </t>
       </x:lt>
       <x:lt>
         <t>
-          Redirection offering a choice of matching resources for use by
-          reactive content negotiation (&reactive-negotiation;). This
-          is status code <x:ref>300 (Multiple Choices)</x:ref>.
+          Redirection to a different resource, identified by the
+          <x:ref>Location</x:ref> field, that can represent an indirect
+          response to the request, as in the <x:ref>303 (See Other)</x:ref>
+          status code.
         </t>
       </x:lt>
       <x:lt>
         <t>
-          Other kinds of redirection, such as to a cached result (status code <x:ref>304
-          (Not Modified)</x:ref>, see &status-304;). 
+          Redirection to a previously cached result, as in the
+          <x:ref>304 (Not Modified)</x:ref> status code.
         </t>
       </x:lt>
@@ -2901 +2908 @@
 <x:note>
   <t>
-    &Note; In HTTP/1.0, only the status codes <x:ref>301 (Moved Permanently)</x:ref>
-    and <x:ref>302 (Found)</x:ref> were defined for the first type of redirect,
-    and the second type did not exist at all (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>).
-    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 <x:ref>303 (See Other)</x:ref> (<xref target="RFC2068" x:fmt="," x:sec="10.3.4"/>).
-    As user agents did not change their behavior to maintain backwards
-    compatibility, the first revision of HTTP/1.1 added yet another status code,
-    <x:ref>307 (Temporary Redirect)</x:ref>, for which the backwards
-    compatibility problems did not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>).
-    Over 10 years later, most user agents still do method rewriting for status codes
-    <x:ref>301</x:ref> and <x:ref>302</x:ref>, therefore this specification makes that behavior
-    conformant in case the original request was POST.
+    &Note; In HTTP/1.0, the status codes <x:ref>301 (Moved Permanently)</x:ref>
+    and <x:ref>302 (Found)</x:ref> were defined for the first type of redirect
+    (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>). Early user agents split
+    on whether the method applied to the redirect target would be the same as
+    the original request or would be rewritten as GET. Although HTTP
+    originally defined the former semantics for <x:ref>301</x:ref> and
+    <x:ref>302</x:ref> (to match its original implementation at CERN), and
+    defined <x:ref>303 (See Other)</x:ref> to match the latter semantics,
+    prevailing practice gradually converged on the latter semantics for
+    <x:ref>301</x:ref> and <x:ref>302</x:ref> as well. The first revision of
+    HTTP/1.1 added <x:ref>307 (Temporary Redirect)</x:ref> to indicate the
+    former semantics without being impacted by divergent practice.
+    Over 10 years later, most user agents still do method rewriting for
+    <x:ref>301</x:ref> and <x:ref>302</x:ref>; therefore, this specification
+    makes that behavior conformant when the original request is POST.
   </t>
 </x:note>
-<t>
-   A <x:ref>Location</x:ref> header field on a 3xx response indicates that a
-   client &MAY; automatically redirect to the URI provided; see
-   <xref target="header.location"/>.
-</t>
-<t>
-   Note that for methods not known to be "safe", as defined in <xref target="safe.methods"/>,
-   automatic redirection needs to done with care, since the redirect might
-   change the conditions under which the request was issued.
-</t>
 <t>
    Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,