Subject: NEW ISSUE: cacheability of status 303

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jul 2007 10:38:16 +0200

Hi,

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

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 13 Jul 2007 21:07:32 -0700

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

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2007 20:20:26 -0700

Now i70;
   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70

Cheers,

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Jul 2007 18:01:47 +0200

>   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70

For the record: I think that the text proposed by Roy is a big 
improvement, and that we should adopt it as-is.

For now, I have integrated it into 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#status.303> 

Also note that I added the following sentence to the Changes section 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.section.F.4>):

	"Clarify that 303 responses can be cacheable. (Section 10.3.4)"

Best regards, Julian