Re: AW: Content negotiation flamewar (was: Re: "Hash URIs" and content negotiation)

On 13 Nov 2006, at 12:03, Svensson, Lars wrote:
> So, someone wants to access http://example.com/resources/foo which is
> the URI for the resource "foo". In the accept-header, the client
> indicates that it prefers application/rdf+xml . The server finds out
> that it has a rdf/xml representation under
> http://example.com/resources/foo.rdf and sends this back WITHOUT A
> REDIRECT. Instead it sets the Content-Location header to
> http://example.com/resources/foo.rdf to indicate that the returned
> content was not at the requested URI, but at the specified location.
> Similar of course for all other formats (like text/html).

Yes, I think that's a good way to do content negotiation.

> On the surface it seems clean, but something tells me that this is not
> compatible with http-range-14 ...

This is compatible *if* foo is an information resource (that is, its  
state can be expressed in a message).

If foo is another kind of resources (e.g. a person), then you *must*  
do a 303 redirect to the location where a description of foo is  
available. You can 303-redirect to different locations based on  
accept headers. Post-httpRange-14, the only way to serve a  
description of a non-information resource without a second request is  
to use hash URIs.

Which brings us back to the start of the thread: If http:// 
example.com/resources#Bob is a non-information resource, how to  
correctly serve both HTML and RDF descriptions? The problem is that  
the semantics of a fragment identifier depend on the content type. I  
wonder if this means we also have to do a 303 at http://example.com/ 
resources before we can serve a description of #Bob.

Richard


>
> Can anyone please tell me I'm wrong?
>
> Lars
> -- 
> Dr. Lars G. Svensson
> Deutsche Nationalbibliothek
> Informationstechnik
> Adickesallee 1
> 60322 Frankfurt
> http://www.d-nb.de/
>

Received on Monday, 13 November 2006 13:41:04 UTC