- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 12 Jul 2007 04:22:29 -0700
- To: Giovanni Tummarello <g.tummarello@gmail.com>
- Cc: W3C TAG <www-tag@w3.org>, Eyal Oren <eyal.oren@deri.org>, Julian Reschke <julian.reschke@greenbytes.de>
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.
....Roy
Received on Thursday, 12 July 2007 11:22:37 UTC