Re: [VM] [Fwd: http-range resolution - should we ask purl.org to make 303 redirects possible? (DC, RSS1, ...)]

At 10:23 PM 7/15/2005 +0100, Dan Brickley wrote:
>fyi...
>
>Guess I should've cc:'d the WG list. I just asked TAG
>whether a 302 response on the dc:title URI is something they
>can live with.

I don't yet see a response to [1]your query in the www-tag archive.
Have you had any indication of a leaning?

   [1] http://lists.w3.org/Archives/Public/www-tag/2005Jul/0012.html

I mentioned this question to TBL.  His off-the-cuff response was that
in his opinion none of the other 3xx responses had appropriate
semantics for the purposes of httpRange-14.  Reading the HTTP1.1
spec myself, I'm quite inclined to agree.

>Message-ID: <42D81E4A.5070600@w3.org>
>Date: Fri, 15 Jul 2005 21:36:26 +0100
>From: Dan Brickley <danbri@w3.org>
>To: www-tag@w3.org
>Subject: http-range resolution - should we ask purl.org to make 303 redirects
> possible? (DC, RSS1, ...)
...
>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 is
>the relevant chunk of HTTP 1.1 spec:
>
>302 Found: The requested resource resides temporarily under a different URI
>
>303 See Other: The response to the request can be found under a 
>different URI
>       and SHOULD be retrieved using a GET method on that resource.

My literalist reading of those two definitions notes with emphasis
the words _resides_ in the 302 case and _response to the request_
in the 303 case.

Given arbitrary instances of RDF resources, it would be inappropriate
to say that all such resources _reside_ under some URI.  (DanBri's
home page resides in the Web but the owner of DanBri's home page
most likely should not be said to also reside in the Web.)

On the other hand, any RDF application doing an HTTP GET on a
Property or Class name is most desirous of a piece of an RDF
graph providing some clues about that Property or Class.  Thus,
it is very appropriate to talk about the "response to the request" quite
independently of the named Resource itself.

>One section of the HTTP spec lends some weight to the idea that
>WebArch + HTTP justifies the current Purl.org 302 behaviour:
>
>[[
...
>Many pre-HTTP/1.1 user agents do not understand the 303
>status. When interoperability with such clients is a concern, the
>302 status code may be used instead, since most user agents react
>to a 302 response as described here for 303.
>]]
>
>I'm inclined to read that as HTTP/1.1 blessing for the Purl.org
>practice of sending 302s, but am interested to hear a TAG perspective...

I say this is (token) blessing for servers who think that they are talking
with a pre-HTTP/1.1 user agent.  I expect that at the time this was
written, most people expected that "user agent" referred to something
that was likely to render the response for direct human viewing.

Going forward, I'd prefer that we in the SemWeb community not
push to get 302 be normatively endorsed as a backwards-compatible
option for 303.  I think the implementation cost in the future of having
to disambiguate these cases when appropriate will be greater than
the cost today to modify existing services.

Received on Tuesday, 16 August 2005 13:31:01 UTC