Ignore:
Timestamp:
Sep 1, 2011, 1:55:31 AM (8 years ago)
Author:
julian.reschke@…
Message:

explain types of redirects, history of changes, and allow POST->GET rewriting for 301/302 (see [160])

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1427 r1428  
    2525  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     27  <!ENTITY agent-driven-negotiation    "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2728  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    15671568<t>
    15681569   This class of status code indicates that further action needs to be
    1569    taken by the user agent in order to fulfill the request.  The action
    1570    required &MAY; be carried out by the user agent without interaction
    1571    with the user if and only if the method used in the second request is
    1572    known to be "safe", as defined in <xref target="safe.methods"/>.
    1573    A client &SHOULD; detect infinite redirection loops, since such loops
    1574    generate network traffic for each redirection.
     1570   taken by the user agent in order to fulfill the request.  If the required
     1571   action involves a subsequent HTTP request, it &MAY; be carried out by the
     1572   user agent without interaction with the user if and only if the method used
     1573   in the second request is known to be "safe", as defined in
     1574   <xref target="safe.methods"/>.
     1575</t>
     1576<t>
     1577   There are several types of redirects:
     1578   <list style="numbers">
     1579      <x:lt>
     1580        <t>
     1581          Redirects of the request to another URI, either temporarily or
     1582          permanently. The new URI is specified in the Location header field.
     1583          In this specification, the status codes 301 (Moved Permanently),
     1584          302 (Found), and 307 (Temporary Redirect) fall under this category.
     1585        </t>
     1586      </x:lt>
     1587      <x:lt>
     1588        <t>
     1589          Redirection to a new location that represents an indirect response to
     1590          the request, such as the result of a POST operation to be retrieved
     1591          with a subsequent GET request. This is status code 303 (See Other).
     1592        </t>
     1593      </x:lt>
     1594      <x:lt>
     1595        <t>
     1596          Redirection offering a choice of matching resources for use by
     1597          agent-driven content negotiation (&agent-driven-negotiation;). This
     1598          is status code 300 (Multiple Choices).
     1599        </t>
     1600      </x:lt>
     1601      <x:lt>
     1602        <t>
     1603          Other kinds of redirection, such as to a cached result (status code 304
     1604          (Not Modified)).
     1605        </t>
     1606      </x:lt>
     1607   </list>
     1608</t>
     1609<x:note>
     1610  <t>
     1611    <x:h>Note:</x:h> In HTTP/1.0, only the status codes 301 (Moved Permanently)
     1612    and 302 (Found) were defined for the first type of redirect, and the second
     1613    type did not exist at all (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>).
     1614    However it turned out that web forms using POST expected redirects to change
     1615    the operation for the subsequent request to retrieval (GET). To address this
     1616    use case, HTTP/1.1 introduced the second type of redirect with the status
     1617    code 303 (See Other) (<xref target="RFC2068" x:fmt="," x:sec="10.3.4"/>).
     1618    As user agents did not change their behavior to maintain backwards
     1619    compatibility, the first revision of HTTP/1.1 added yet another status code,
     1620    307 (Temporary Redirect), for which the backwards compatibility problems did
     1621    not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>).
     1622    Over 10 years later, most user agents still do method rewriting for
     1623    status codes 301 and 302, therefore this specification makes that behavior
     1624    compliant in case the original request was POST.
     1625  </t>
     1626</x:note>
     1627<t>
     1628   Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,
     1629   "infinite" redirection loops).
    15751630</t>
    15761631<x:note>
    … …  
    16461701<x:note>
    16471702  <t>
    1648     <x:h>Note:</x:h> When automatically redirecting a POST request after
    1649     receiving a 301 status code, some existing HTTP/1.0 user agents
    1650     will erroneously change it into a GET request.
     1703    <x:h>Note:</x:h> For historic reasons, user agents &MAY; change the
     1704    request method from POST to GET for the subsequent request. If this
     1705    behavior is undesired, status code 307 (Temporary Redirect) can be used
     1706    instead.
    16511707  </t>
    16521708</x:note>
    … …  
    16771733<x:note>
    16781734  <t>
    1679     <x:h>Note:</x:h> HTTP/1.0 (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>)
    1680     and the first version of HTTP/1.1 (<xref target="RFC2068" x:fmt="," x:sec ="10.3.3"/>)
    1681     specify that the client is not allowed to change the method on the
    1682     redirected request.  However, most existing user agent implementations
    1683     treat 302 as if it were a 303 response, performing a GET on the Location
    1684     field-value regardless of the original request method. Therefore, a
    1685     previous version of this specification
    1686     (<xref target="RFC2616" x:fmt="," x:sec="10.3.3"/>) has added the
    1687     status codes
    1688     <xref target="status.303" format="none">303</xref> and
    1689     <xref target="status.307" format="none">307</xref> for servers that wish
    1690     to make unambiguously clear which kind of reaction is expected of the
    1691     client.
     1735    <x:h>Note:</x:h> For historic reasons, user agents &MAY; change the
     1736    request method from POST to GET for the subsequent request. If this
     1737    behavior is undesired, status code 307 (Temporary Redirect) can be used
     1738    instead.
     1739    <cref anchor="issue312">but see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/312"/></cref>
    16921740  </t>
    16931741</x:note>
    … …  
    36173665</t>
    36183666<t>
    3619   Failed to consider that there are
    3620   many other request methods that are safe to automatically redirect,
    3621   and further that the user agent is able to make that determination
    3622   based on the request method semantics.
     3667  Failed to consider that there are many other request methods that are safe
     3668  to automatically redirect, and further that the user agent is able to make
     3669  that determination based on the request method semantics.
     3670  Furthermore, allow user agents to rewrite the method from POST to GET
     3671  for status codes 301 and 302.
    36233672  (Sections <xref format="counter" target="status.301"/>,
    36243673  <xref format="counter" target="status.302"/> and
    … …  
    42724321  <list style="symbols">
    42734322    <t>
     4323      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/160"/>:
     4324      "Redirects and non-GET methods"
     4325    </t>
     4326    <t>
    42744327      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/310"/>:
    42754328      "clarify 303 redirect on HEAD"
Note: See TracChangeset for help on using the changeset viewer.