Changeset 2087 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 05/01/13 10:21:45 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2086 r2087 1128 1128 1129 1129 <section title="Safe Methods" anchor="safe.methods"> 1130 <iref item="safe" primary="true"/> 1131 <t> 1132 Request methods are considered "<x:dfn anchor="safe">safe</x:dfn>" if 1130 <iref item="safe" primary="true"/> 1131 <x:anchor-alias value="safe"/> 1132 <t> 1133 Request methods are considered "<x:dfn>safe</x:dfn>" if 1133 1134 their defined semantics are essentially read-only; i.e., the client does 1134 1135 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 2863 2864 further action needs to be taken by the user agent in order to fulfill the 2864 request. 2865 request. If a <x:ref>Location</x:ref> header field 2866 (<xref target="header.location"/>) is provided, the user agent &MAY; 2867 automatically redirect its request to the URI referenced by the Location 2868 field value, even if the specific status code is not understood. 2869 Automatic redirection needs to done with care for methods not known to be 2870 <x:ref>safe</x:ref>, as defined in <xref target="safe.methods"/>, since 2871 the user might not wish to redirect an unsafe request. 2865 2872 </t> 2866 2873 <t> … … 2869 2876 <x:lt> 2870 2877 <t> 2871 Redirects of the request to another URI, either temporarily or2872 permanently. The new URI is specified in the <x:ref>Location</x:ref>2873 header field. In this specification, the status codes <x:ref>3012874 (Moved Permanently)</x:ref>,<x:ref>302 (Found)</x:ref>, and2875 <x:ref>307 (Temporary Redirect)</x:ref> fall under this category.2878 Redirects that indicate the resource might be available at a 2879 different URI, as provided by the <x:ref>Location</x:ref> field, 2880 as in the status codes <x:ref>301 (Moved Permanently)</x:ref>, 2881 <x:ref>302 (Found)</x:ref>, and 2882 <x:ref>307 (Temporary Redirect)</x:ref>. 2876 2883 </t> 2877 2884 </x:lt> 2878 2885 <x:lt> 2879 2886 <t> 2880 Redirection to a new location that represents an indirect response to 2881 the request, such as the result of a POST operation to be retrieved 2882 with a subsequent GET request. This is status code <x:ref>303 (See 2883 Other)</x:ref>. 2887 Redirection that offers a choice of matching resources, each capable 2888 of representing the original request target, as in the 2889 <x:ref>300 (Multiple Choices)</x:ref> status code. 2884 2890 </t> 2885 2891 </x:lt> 2886 2892 <x:lt> 2887 2893 <t> 2888 Redirection offering a choice of matching resources for use by 2889 reactive content negotiation (&reactive-negotiation;). This 2890 is status code <x:ref>300 (Multiple Choices)</x:ref>. 2894 Redirection to a different resource, identified by the 2895 <x:ref>Location</x:ref> field, that can represent an indirect 2896 response to the request, as in the <x:ref>303 (See Other)</x:ref> 2897 status code. 2891 2898 </t> 2892 2899 </x:lt> 2893 2900 <x:lt> 2894 2901 <t> 2895 Other kinds of redirection, such as to a cached result (status code <x:ref>3042896 (Not Modified)</x:ref>, see &status-304;).2902 Redirection to a previously cached result, as in the 2903 <x:ref>304 (Not Modified)</x:ref> status code. 2897 2904 </t> 2898 2905 </x:lt> … … 2901 2908 <x:note> 2902 2909 <t> 2903 &Note; In HTTP/1.0, only the status codes <x:ref>301 (Moved Permanently)</x:ref> 2904 and <x:ref>302 (Found)</x:ref> were defined for the first type of redirect, 2905 and the second type did not exist at all (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>). 2906 However it turned out that web forms using POST expected redirects to change 2907 the operation for the subsequent request to retrieval (GET). To address this 2908 use case, HTTP/1.1 introduced the second type of redirect with the status 2909 code <x:ref>303 (See Other)</x:ref> (<xref target="RFC2068" x:fmt="," x:sec="10.3.4"/>). 2910 As user agents did not change their behavior to maintain backwards 2911 compatibility, the first revision of HTTP/1.1 added yet another status code, 2912 <x:ref>307 (Temporary Redirect)</x:ref>, for which the backwards 2913 compatibility problems did not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>). 2914 Over 10 years later, most user agents still do method rewriting for status codes 2915 <x:ref>301</x:ref> and <x:ref>302</x:ref>, therefore this specification makes that behavior 2916 conformant in case the original request was POST. 2910 &Note; In HTTP/1.0, the status codes <x:ref>301 (Moved Permanently)</x:ref> 2911 and <x:ref>302 (Found)</x:ref> were defined for the first type of redirect 2912 (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>). Early user agents split 2913 on whether the method applied to the redirect target would be the same as 2914 the original request or would be rewritten as GET. Although HTTP 2915 originally defined the former semantics for <x:ref>301</x:ref> and 2916 <x:ref>302</x:ref> (to match its original implementation at CERN), and 2917 defined <x:ref>303 (See Other)</x:ref> to match the latter semantics, 2918 prevailing practice gradually converged on the latter semantics for 2919 <x:ref>301</x:ref> and <x:ref>302</x:ref> as well. The first revision of 2920 HTTP/1.1 added <x:ref>307 (Temporary Redirect)</x:ref> to indicate the 2921 former semantics without being impacted by divergent practice. 2922 Over 10 years later, most user agents still do method rewriting for 2923 <x:ref>301</x:ref> and <x:ref>302</x:ref>; therefore, this specification 2924 makes that behavior conformant when the original request is POST. 2917 2925 </t> 2918 2926 </x:note> 2919 <t>2920 A <x:ref>Location</x:ref> header field on a 3xx response indicates that a2921 client &MAY; automatically redirect to the URI provided; see2922 <xref target="header.location"/>.2923 </t>2924 <t>2925 Note that for methods not known to be "safe", as defined in <xref target="safe.methods"/>,2926 automatic redirection needs to done with care, since the redirect might2927 change the conditions under which the request was issued.2928 </t>2929 2927 <t> 2930 2928 Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,
Note: See TracChangeset
for help on using the changeset viewer.