i70: cacheability of status 303

Any other thoughts on this? It's a fairly substantial change. David B  
suggested a few re-wordings, but I don't see agreement around those yet.

Personally -- there are a few editorial changes that I'd make, as the  
proposal is a bit wordy;
    - "in order to obtain a representation corresponding to the  
response, be redirected again, or end with an error status" is  
superfluous, as is "generally" and "by Cache-Control or Expires  
header fields."
    - "...transferred by the server over HTTP" seems clunky, as does  
"follow-on", although I don't have any immediate suggestion for either.

Also, we seem to be implicitly dropping the note to implementers WRT  
HTTP/1.0 support for 303. Are we confident that this is no longer a  
problem?

Finally, 2616 makes it a SHOULD-level requirement that the Location  
URI is a different URI. Are we dropping that explicitly? One easy fix  
would be to change "The Location URI indicates a resource..." to "The  
Location URI SHOULD indicate a different resource..."

Otherwise, it looks good to me. I've copied the original spec text  
below for comparison.


On 14/07/2007, at 2:07 PM, Roy T. Fielding wrote:

>
> On Jul 13, 2007, at 1:38 AM, Julian Reschke wrote:
>> see discussion over at the W3C TAG mailing list (<http:// 
>> www.w3.org/mid/06EB9571-9EFE-42EF-833E-EB630D422227@gbiv.com>) and  
>> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon- 
>> rfc2616bis-latest.html#rfc.issue.cacheability-of-303>).
>
> My suggestion is to change the entire section to:
>
> ==============
> 10.3.4.  303 See Other
>
>    The server directs the user agent to a different resource,  
> indicated
>    by a URI in the Location header field, that provides an indirect
>    response to the original request.  The user agent MAY perform a GET
>    request on the URI in the Location field in order to obtain a
>    representation corresponding to the response, be redirected again,
>    or end with an error status.  The Location URI is not a substitute
>    reference for the originally requested resource.
>
>    The 303 status is generally applicable to any HTTP method.  It is
>    primarily used to allow the output of a POST action to redirect
>    the user agent to a selected resource, since doing so provides the
>    information corresponding to the POST response in a form that
>    can be separately identified, bookmarked, and cached independent
>    of the original request.
>
>    A 303 response to a GET request indicates that the requested
>    resource does not have a representation of its own that can be
>    transferred by the server over HTTP.  The Location URI indicates a
>    resource that is descriptive of the requested resource such that
>    the follow-on representation may be useful without implying that
>    that it adequately represents the previously requested resource.
>    Note that answers to the questions of what can be represented, what
>    representations are adequate, and what might be a useful  
> description
>    are outside the scope of HTTP and thus entirely determined by the
>    resource owner(s).
>
>    A 303 response SHOULD NOT be cached unless it is indicated as
>    cacheable by Cache-Control or Expires header fields.  Except for
>    responses to a HEAD request, the entity of a 303 response SHOULD
>    contain a short hypertext note with a hyperlink to the Location  
> URI.
> ==============
>

Original text:

> 10.3.4 303 See Other
>
> The response to the request can be found under a different URI and  
> SHOULD be retrieved using a GET method on that resource. This  
> method exists primarily to allow the output of a POST-activated  
> script to redirect the user agent to a selected resource. The new  
> URI is not a substitute reference for the originally requested  
> resource. The 303 response MUST NOT be cached, but the response to  
> the second (redirected) request might be cacheable.
>
> The different URI SHOULD be given by the Location field in the  
> response. Unless the request method was HEAD, the entity of the  
> response SHOULD contain a short hypertext note with a hyperlink to  
> the new URI(s).
>
>       Note: Many pre-HTTP/1.1 user agents do not understand the 303
>       status. When interoperability with such clients is a concern,  
> the
>       302 status code may be used instead, since most user agents  
> react
>       to a 302 response as described here for 303.



--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 13 November 2007 05:17:17 UTC