[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] HTTP/1.1 302 Moved Temporarily
On Feb 9, 2010, at 5:14 AM, Hammond, Tony wrote:
> Thanks, Robert:
>
> I suppose this is where Tomcat gets it from:
>
> LocalStrings.properties:sc.302=Moved Temporarily
>
> ../apache-tomcat-6.0.24-src/java/org/apache/tomcat/util/http/res
>
> Agree that RFC 2616 allows for local variants - although I presume it had
> language translations in mind rather than alternate wordings. ;) Important
> especially because the TAG clearly has a semantic agenda for HTTP status
> codes.
I don't think we should blame Tomcat since it was the W3C that (needlessly) changed the wording.
> Anyway this is just real sloppy practice by Tomcat. Words ought to mean
> something. And adherence to standards too.
Words are ambiguous, which is why we (and everyone else who wants a stable system) ignore the text and observe the status code. I would also argue that "Found" is more ambiguous than "Temporarily Moved."
> But I do agree with John's reply here that 302 might not be the clearest
> response that an HS could give - 303 and 307 being the preferred modern
> variants.
The only difference seems to be that clients can (but apparently don't) transfer POST data over a 302 redirect but not a 303/307. What benefit does the 303/307 provide that we should risk breaking lots of existing clients? Given that the whole point of the handle HTTP proxy is making handles accessible to existing clients, wouldn't that defeat the purpose?
After reading the comments on John Erickson's blog (http://bitwacker.wordpress.com/2010/02/04/dois-uris-and-cool-resolution, which I assumed started this discussion), the 303 is preferable to a 302 for "non-informational objects" because of a TAG finding that declared that to be the case. That would require the proxy to determine from the handle values whether the object is a real-world or online object. Or are you proposing that _all_ handle proxy redirects use status code 303?
> I don't see how an HS can properly defer to a downstream server. This is
> something that an HS needs to take responsibility for. Or at least the proxy
> server operated by an RA. An RA member cannot impose an alternate semantic
> reading over the RA default, surely?
The RA member already can, if by "RA member" you mean the entity that owns the URL to which the handle resolves. I don't understand the problem with RA members providing RDF for their own objects. How is this different from the members putting metadata in the HEAD section of their HTML files? Or is it just that the RAs should be able to intercept the RDF requests (at the proxy) before getting to the end point? I can see the value in that.
> We really need a more graceful interface between handle and HTTP.
True. For starters, handle-not-found responses should return a 404 response code. We can work on other points, such as the proxy returning RDF+XML pointers.
The existing multiple-resolution mechanism (10320/loc) can be tweaked to do this by translating the "Accepts" HTTP header into a request for a location with a specific attribute. That way you could build a handle or DOI that returned the proper link based on any number of selection criteria (which can be overridden by URL parameters).
Thanks,
Sean
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info