Ignore:
Timestamp:
05/01/13 10:21:45 (10 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2086 r2087  
    13361336      <div id="rfc.iref.s.1"></div>
    13371337      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
    1338       <p id="rfc.section.4.2.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state
     1338      <p id="rfc.section.4.2.1.p.1">Request methods are considered "<dfn>safe</dfn>" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state
    13391339         change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe
    13401340         method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
    … …  
    24822482      <div id="rfc.iref.72"></div>
    24832483      <div id="rfc.iref.s.4"></div>
    2484       <p id="rfc.section.6.4.p.1">The <dfn>3xx (Redirection)</dfn> class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
     2484      <p id="rfc.section.6.4.p.1">The <dfn>3xx (Redirection)</dfn> class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If
     2485         a <a href="#header.location" class="smpl">Location</a> header field (<a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.2</a>) is provided, the user agent <em class="bcp14">MAY</em> automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is
     2486         not understood. Automatic redirection needs to done with care for methods not known to be <a href="#safe.methods" class="smpl">safe</a>, as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, since the user might not wish to redirect an unsafe request.
    24852487      </p>
    24862488      <p id="rfc.section.6.4.p.2">There are several types of redirects: </p>
    24872489      <ol>
    24882490         <li>
    2489             <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the <a href="#header.location" class="smpl">Location</a> header field. In this specification, the status codes <a href="#status.301" class="smpl">301
    2490                   (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.
     2491            <p>Redirects that indicate the resource might be available at a different URI, as provided by the <a href="#header.location" class="smpl">Location</a> field, as in 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>.
    24912492            </p>
    24922493         </li>
    24932494         <li>
    2494             <p>Redirection to a new location that represents an indirect response to the request, such as the result of a POST operation
    2495                to be retrieved with a subsequent GET request. This is status code <a href="#status.303" class="smpl">303 (See
    2496                   Other)</a>.
     2495            <p>Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> status code.
    24972496            </p>
    24982497         </li>
    24992498         <li>
    2500             <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.4.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
     2499            <p>Redirection to a different resource, identified by the <a href="#header.location" class="smpl">Location</a> field, that can represent an indirect response to the request, as in the <a href="#status.303" class="smpl">303 (See Other)</a> status code.
    25012500            </p>
    25022501         </li>
    25032502         <li>
    2504             <p>Other kinds of redirection, such as to a cached result (status code <a href="p4-conditional.html#status.304" class="smpl">304
    2505                   (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
     2503            <p>Redirection to a previously cached result, as in the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code.
    25062504            </p>
    25072505         </li>
    25082506      </ol>
    25092507      <div class="note" id="rfc.section.6.4.p.3">
    2510          <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
    2511             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.2"><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
    2512             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 <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>, therefore this specification makes that behavior conformant in case the original request was POST.
     2508         <p> <b>Note:</b> In HTTP/1.0, 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 (<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>). Early user agents split on whether the method applied to the redirect target would be the same as the original request
     2509            or would be rewritten as GET. Although HTTP originally defined the former semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> (to match its original implementation at CERN), and defined <a href="#status.303" class="smpl">303 (See Other)</a> to match the latter semantics, prevailing practice gradually converged on the latter semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> as well. The first revision of HTTP/1.1 added <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still
     2510            do method rewriting for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>; therefore, this specification makes that behavior conformant when the original request is POST.
    25132511         </p>
    25142512      </div>
    2515       <p id="rfc.section.6.4.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.2</a>.
    2516       </p>
    2517       <p id="rfc.section.6.4.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
    2518          issued.
    2519       </p>
    2520       <p id="rfc.section.6.4.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
    2521       </p>
    2522       <div class="note" id="rfc.section.6.4.p.7">
    2523          <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
     2513      <p id="rfc.section.6.4.p.4">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
     2514      </p>
     2515      <div class="note" id="rfc.section.6.4.p.5">
     2516         <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
    25242517         </p>
    25252518      </div>
    … …  
    29852978               <tr>
    29862979                  <td class="left">ETag</td>
    2987                   <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     2980                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    29882981               </tr>
    29892982               <tr>
    29902983                  <td class="left">Last-Modified</td>
    2991                   <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
     2984                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    29922985               </tr>
    29932986               <tr>
    … …  
    31433136         makes to header field or status code semantics. If the new method is cacheable, its definition ought to describe how, and
    31443137         under what conditions, a cache can store a response and use it to satisfy a subsequent request. If the new method can be made
    3145          conditional (<a href="#Part4" id="rfc.xref.Part4.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), the definition ought to describe how to respond when the condition is false. Likewise, if the new method might have some
     3138         conditional (<a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), the definition ought to describe how to respond when the condition is false. Likewise, if the new method might have some
    31463139         use for partial response semantics (<a href="#Part5" id="rfc.xref.Part5.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), it ought to document this too.
    31473140      </p>
    … …  
    45694562                     </ul>
    45704563                  </li>
    4571                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">6.4</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">7.2</a>, <a href="#rfc.xref.Part4.14">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
    4572                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.13">7.2</a></li>
    4573                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.12">7.2</a></li>
     4564                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
     4565                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
     4566                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a></li>
    45744567                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">5.2</a></li>
    45754568                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>
    … …  
    45774570                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
    45784571                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">6.1</a></li>
    4579                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.11">6.4</a></li>
     4572                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">6.1</a></li>
    45804573                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">6.1</a></li>
    45814574                     </ul>
    … …  
    46414634                     </ul>
    46424635                  </li>
    4643                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.2.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#rfc.xref.RFC2068.3">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul>
    4644                         <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.4</a></li>
    4645                         <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li>
     4636                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.2.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul>
     4637                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li>
    46464638                     </ul>
    46474639                  </li>
    … …  
    46534645                     </ul>
    46544646                  </li>
    4655                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a>, <a href="#rfc.xref.RFC2616.2">6.4</a>, <a href="#RFC2616"><b>11.2</b></a><ul>
    4656                         <li><em>Section 10.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.2">6.4</a></li>
     4647                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a>, <a href="#RFC2616"><b>11.2</b></a><ul>
    46574648                        <li><em>Section 14.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a></li>
    46584649                     </ul>

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

    r2086 r2087  
    11281128
    11291129<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
    11331134   their defined semantics are essentially read-only; i.e., the client does
    11341135   not request, and does not expect, any state change on the origin server
    … …  
    28622863   The <x:dfn>3xx (Redirection)</x:dfn> class of status code indicates that
    28632864   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.
    28652872</t>
    28662873<t>
    … …  
    28692876      <x:lt>
    28702877        <t>
    2871           Redirects of the request to another URI, either temporarily or
    2872           permanently. The new URI is specified in the <x:ref>Location</x:ref>
    2873           header field. In this specification, the status codes <x:ref>301
    2874           (Moved Permanently)</x:ref>, <x:ref>302 (Found)</x:ref>, and
    2875           <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>.
    28762883        </t>
    28772884      </x:lt>
    28782885      <x:lt>
    28792886        <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.
    28842890        </t>
    28852891      </x:lt>
    28862892      <x:lt>
    28872893        <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.
    28912898        </t>
    28922899      </x:lt>
    28932900      <x:lt>
    28942901        <t>
    2895           Other kinds of redirection, such as to a cached result (status code <x:ref>304
    2896           (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.
    28972904        </t>
    28982905      </x:lt>
    … …  
    29012908<x:note>
    29022909  <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.
    29172925  </t>
    29182926</x:note>
    2919 <t>
    2920    A <x:ref>Location</x:ref> header field on a 3xx response indicates that a
    2921    client &MAY; automatically redirect to the URI provided; see
    2922    <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 might
    2927    change the conditions under which the request was issued.
    2928 </t>
    29292927<t>
    29302928   Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,
Note: See TracChangeset for help on using the changeset viewer.