- From: Dan Brickley <danbri@w3.org>
- Date: Fri, 15 Jul 2005 21:36:26 +0100
- To: www-tag@w3.org
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