caching HTTP 303 responses

Eyal Oren <eyal.oren@deri.org> writes:
> 
> I've a question regarding serving RDF content using HTTP 303 redirects. For 
> example, foaf:name [1] redirects to http://xmlns.com/foaf/spec using HTTP 
> 303.  The, I believe relevant, RFC 2616 says that HTTP 303 responses MUST 
> NOT be cached, although the result may be cached [2].
> 
> Does this mean, that I have to check every single time what foaf:name 
> redirects to? Or am I allowed to remember that foaf:name redirects to its 
> spec? Squid for example will not cache this redirect exactly because it is 
> a 303.  
> 
> Unless I'm misunderstanding something, it seems that when I'm processing 
> lots of documents by de-referencing their URIs, I must dereference 
> foaf:name every single time, only to be redirected to the same location, 
> after which I can use my local copy.  Requesting this HTTP header using eg.  
> curl takes around 0.33s, which I'd think is rather a lot when processing 
> thousands of foaf files containing tens of foaf properties each.
> 
> My question: why are HTTP 303 codes being suggested [3],[4] instead of 
> cacheable response such as 301 or was caching not an issue in drafting 
> these suggestions?

I picked 303 because its name and descriptive text were relatively clear
about the redirection being to a different resource.  By contrast, the
text on 301 ("the requested resource has been assigned a new permanent
URI") suggests that both old and new URIs identify the same thing -- so
if one is being logically pedandic, one can't do a 301 redirect from a
non-information-resource URI to an information-resource URI.   With 303,
one can do that.

The prohibition against caching is a problem.   I don't have a good
solution.  Maybe the TAG talked about this?   I don't know why the
redirect is not supposed to be cached.

    -- Sandro

Received on Monday, 9 July 2007 19:45:02 UTC