Subject: i70: cacheability of status 303

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Nov 2007 16:14:01 +1100

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/[email-masked]>) 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/

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 13 Nov 2007 07:38:24 +0100

> HTTP/1.0 support for 303. Are we confident that this is no longer a  

IIRC it's a problem for "Netscape 3" (Mozilla 3).  In HTTP/1.0
compatibility mode servers better stick to 302, compare
http://www.ietf.org/mail-archive/web/tools-discuss/current/msg00818.html

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Nov 2007 15:52:39 +0100

Mark Nottingham wrote:
>    - "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."

+0 -- that is, it is wordy, but I don't think this is a problem.

> HTTP/1.0 support for 303. Are we confident that this is no longer a 

I would lean to "no, it's no problem", unless somebody can point to a 
client that still is in significant use and has that problem. Let's try 
to get rid of *some* of the historical stuff :-).

> 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..."

The requirement is still there ("The server directs the user agent to a 
different resource, indicated by a URI in the Location header 
field..."), it just doesn't use RFC2119 terminology to say that. I 
personally have no problem with that.

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

Best regards, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 14 Nov 2007 11:21:46 +0100

Julian Reschke wrote:
 
> unless somebody can point to a client that still is in significant
> use and has that problem.

Well, I used that client until 2007-06, it is the best available UA
for my platform with its limited resources (as it was).

> Let's try to get rid of *some* of the historical stuff :-).

The HTTP/1.0 compatibility notes in RFC 2616 are correct as far as I
observed it.  UAs not sending a Host: header would be hopeless, that
is where I'd draw the line.

If you want to get rid of historical stuff maybe eliminate "simple
requests" and "simple reponses" if they're still implicitly allowed
somewhere.  

 Frank