W3C home > Mailing lists > Public > www-tag@w3.org > July 2007

Re: http-range-14 303 issue, request for reopening the discussion

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 13 Jul 2007 20:30:56 -0700
Message-Id: <B2CBB064-0498-4CC8-99CD-077D6344E1E3@gbiv.com>
Cc: Giovanni Tummarello <g.tummarello@gmail.com>, W3C TAG <www-tag@w3.org>, Eyal Oren <eyal.oren@deri.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Jul 13, 2007, at 1:33 AM, Julian Reschke wrote:
> Roy T. Fielding wrote:
>> On Jul 12, 2007, at 3:27 AM, Giovanni Tummarello wrote:
>>> Greetings,
>>>
>>> these days a discussion broke out on the Linking Open Data on the  
>>> Semantic Web mailing list (community project of the SWEO internet  
>>> group) about the perceived need to revise the http-range-14  
>>> outcome. Chris suggested that we refer to this group be contacted.
>>>
>>> The issue we see is that 303 is an unfortunate return code for  
>>> semantic web URIs as the HTTP specs state that such responses  
>>> MUST NOT be cache. This can be easily seen as having very  
>>> negative consequences on implementations (e.g. the only way to  
>>> speed up processing of rdf files would be to patch web proxies  
>>> and/or browsers to violate the standard).
>> Umm, I have no idea why the specification says that.  Cache-control
>> can be used to override it.
>>    A response received with any other status code MUST NOT be  
>> returned
>>    in a reply to a subsequent request unless there are Cache-Control
>>    directives or another header(s) that explicitly allow it. For
>>    example, these include the following: an Expires header (section
>>    14.21); a "max-age", "must-revalidate", "proxy-revalidate",  
>> "public"
>>    or "private" Cache-Control directive (section 14.9).
>> It looks like the contradiction was added to RFC 2616 when somebody
>> decided to convert the commentary on its use with POST into a fixed
>> requirement on all 303 responses.  It is just a bug in the spec.
>
> Seems that allowing to override the non-cacheability just like with  
> other status codes is the way to go, and will not break anything  
> (in the worst case, something that could have been cached, won't).
>
> So would it be appropriate just to drop
>
> 	"The 303 response MUST NOT be cached, but the response to the  
> second (redirected) request might be cacheable."
>
> or should we make an attempt to fix that statement?

It would make more sense to rewrite the section -- the reason it got
messed up in the first place is because the definition was cut and
pasted from a discussion on POST rather than a generic description
of the status (see the text of RFC 2068 for a bit of de-evolution).

The current text is
==============
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.
==============

BTW, that note at the end of the current 2616 text is brain dead.

I would 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
Received on Saturday, 14 July 2007 03:31:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:46 GMT