Re: Is 303 really necessary?

Hi Ian,

Although I applaud your efforts at finding a simpler solution, upon
reflection I think I would vote against the "200 + Content-location"
proposal, 
http://iand.posterous.com/a-guide-to-publishing-linked-data-without-red
for these reasons:

1. I think adding a third option to the "use either hash URIs or 303
redirects" guidance will cause more harm then good to the LOD community.
There is already enough confusion over "Should I use a hash URI or a 303
and why?" question.  A third option is likely to create even more
confusion.

2. I don't see the extra network access of 303 as being such a big deal
-- though YMMV -- since even though the 303 response itself is not
supposed to be cached (per RDF 2616), the toucan description document
returned in the following 200 response can (and should) be cached.  In
fact, if you have n slash URIs U1, U2, ... Un etc. that share the same
description document, then with the 200+CL approach the entire
description document would have to be returned n times, whereas with the
303 approach the description document would only be retrieved once: the
rest of the n network access would be short 303 responses.

3. The proposed use of the Content-location header is not aligned with
the RFC 2616 or HTTPbis definitions of its purpose: 
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#page-24
That header does not indicate that the returned representation is *not*
a representation corresponding to the effective request URI.  Rather, it
says that it is *also* a representation corresponding to the
Content-location URI.  I.e., the returned representation is *both* a
representation of a generic *and* a more specific resource.

Best wishes,


-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Thursday, 18 November 2010 22:10:44 UTC