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

How hard would it be to do an errata update to the RFC to fix this?   Or
is this more difficult because there is separate work going on to update
the RFC?

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Roy T. Fielding
> Sent: Friday, July 13, 2007 8:31 PM
> To: Julian Reschke
> Cc: Giovanni Tummarello; W3C TAG; Eyal Oren
> Subject: Re: http-range-14 303 issue, request for reopening 
> the discussion
> 
> 
> 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 Tuesday, 17 July 2007 10:28:58 UTC