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: Thu, 12 Jul 2007 04:22:29 -0700
Message-Id: <06EB9571-9EFE-42EF-833E-EB630D422227@gbiv.com>
Cc: W3C TAG <www-tag@w3.org>, Eyal Oren <eyal.oren@deri.org>, Julian Reschke <julian.reschke@greenbytes.de>
To: Giovanni Tummarello <g.tummarello@gmail.com>

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.

Received on Thursday, 12 July 2007 11:22:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:16 UTC