15/04/08 15:57:31 (14 years ago)

Resolve #70: replace description of 303 status with rewrite proposed by Roy Fielding in <http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0048.html>; leaving ticket open for further discussion.

1 edited


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

    r241 r242  
    12701270  <iref primary="true" item="Status Codes" subitem="303 See Other" x:for-anchor=""/>
    1272    The response to the request can be found under a different URI and
    1273    &SHOULD; be retrieved using a GET method on that resource. This method
    1274    exists primarily to allow the output of a POST-activated script to
    1275    redirect the user agent to a selected resource. The new URI is not a
    1276    substitute reference for the originally requested resource. The 303
    1277    response &MUST-NOT; be cached, but the response to the second
    1278    (redirected) request might be cacheable.
    1279 </t>
    1280 <t>
    1281    The different URI &SHOULD; be given by the Location field in the
    1282    response. Unless the request method was HEAD, the entity of the
    1283    response &SHOULD; contain a short hypertext note with a hyperlink to
    1284    the new URI(s).
    1285   <list><t>
    1286       <x:h>Note:</x:h> Many pre-HTTP/1.1 user agents do not understand the 303
    1287       status. When interoperability with such clients is a concern, the
    1288       302 status code may be used instead, since most user agents react
    1289       to a 302 response as described here for 303.
    1290   </t></list>
     1272   The server directs the user agent to a different resource, indicated
     1273   by a URI in the Location header field, that provides an indirect
     1274   response to the original request.  The user agent &MAY; perform a GET
     1275   request on the URI in the Location field in order to obtain a
     1276   representation corresponding to the response, be redirected again,
     1277   or end with an error status.  The Location URI is not a substitute
     1278   reference for the originally requested resource.
     1281   The 303 status is generally applicable to any HTTP method.  It is
     1282   primarily used to allow the output of a POST action to redirect
     1283   the user agent to a selected resource, since doing so provides the
     1284   information corresponding to the POST response in a form that
     1285   can be separately identified, bookmarked, and cached independent
     1286   of the original request.
     1289   A 303 response to a GET request indicates that the requested
     1290   resource does not have a representation of its own that can be
     1291   transferred by the server over HTTP.  The Location URI indicates a
     1292   resource that is descriptive of the requested resource such that
     1293   the follow-on representation may be useful without implying that
     1294   that it adequately represents the previously requested resource.
     1295   Note that answers to the questions of what can be represented, what
     1296   representations are adequate, and what might be a useful description
     1297   are outside the scope of HTTP and thus entirely determined by the
     1298   resource owner(s).
     1301   A 303 response &SHOULD-NOT; be cached unless it is indicated as
     1302   cacheable by Cache-Control or Expires header fields.  Except for
     1303   responses to a HEAD request, the entity of a 303 response &SHOULD;
     1304   contain a short hypertext note with a hyperlink to the Location URI.
    27692783    </t>
    27702784    <t>
     2785      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70"/>:
     2786      "Cacheability of 303 response"
     2787    </t>
     2788    <t>
    27712789      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76"/>:
    27722790      "305 Use Proxy"
Note: See TracChangeset for help on using the changeset viewer.