http-range resolution - should we ask purl.org to make 303 redirects possible? (DC, RSS1, ...)

Following up from SWBP WG discussion of the http-range resolution,
I had an action to investigate feasibility of purl.org updating their code
to allow purl.org-based namespaces (which include the popular Dublin
Core and RSS1 vocabs) to get HTTP 303 response codes.  Currently
they send a 302.

It seems a change might be possible, if a strong case were made. However it
would cost OCLC non-trivial effort to make the change, so if we are to
ask this, I'd like to be very clear we really want it.

Here's the current state of play:

[[
booboo:~ danbri$ telnet purl.org 80
Trying 132.174.1.35...
Connected to purl.org.
Escape character is '^]'.
GET /dc/elements/1.1/title HTTP/1.1
Host: booboo.danbri.org

HTTP/1.1 302 Found
Date: Fri, 15 Jul 2005 20:15:38 GMT
Server: Apache/1.3.27
Location: http://dublincore.org/2003/03/24/dces#title
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

df
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A 
HREF="http://dublincore.org/2003/03/24/dces#title">here</A>.<P>
</BODY></HTML>
]]


I don't believe the Purl code currently allows namespace owners to
configure the response code.

http://www.w3.org/2001/tag/issues.html?type=1#httpRange-14
doesn't point to the resolution yet, ie.
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

[[
 b) If an "http" resource responds to a GET request with a

      303 (See Other) response, then the resource identified
      by that URI could be any resource;

]]

If the TAG are convinced that this is the only proper response
for that scenario, let's see about getting it into the Purl codebase.

I just wanted to check before making the request, though.

Could you live with "302 Found"?

If we do ask the OCLC/Purl team to change their code, do you
know of any reason why a global change (ie. all Purl redirects)
might be problematic? (eg. browser behaviour quirks, etc).

Perhaps we can 'use the source luke', and propose a peer-reviewed
patch to http://www.oclc.org/esd/purl/docs/files/PURL.2.13.src.tar.gz

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.

One section of the HTTP spec lends some weight to the idea that
WebArch + HTTP justifies the current Purl.org 302 behaviour:

[[      
However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
...  

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...

Dan

Received on Friday, 15 July 2005 20:36:31 UTC