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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 13 Jul 2007 10:33:58 +0200
Message-ID: <469738F6.1060201@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Giovanni Tummarello <g.tummarello@gmail.com>, W3C TAG <www-tag@w3.org>, Eyal Oren <eyal.oren@deri.org>, Julian Reschke <julian.reschke@greenbytes.de>

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?

Best regards, Julian
Received on Friday, 13 July 2007 18:08:09 GMT

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