Re: 200 OK with Content-Location might work: But maybe it can be simpler?

Mike Kelly wrote:
> On Fri, Nov 5, 2010 at 5:33 PM, Antoine Zimmermann
> <antoine.zimmermann@insa-lyon.fr> wrote:
>> Le 05/11/2010 18:25, Giovanni Tummarello a écrit :
>>> How about something that's totally independant from HEADER issues?
>>>
>>> think normal people here. absolutely 0 interest to mess with headers
>>> and http responses.. absolutely no business incentive to do it.
>> Solutions to technical problems are not for little kids, grandmothers and
>> casual Web users. Getting a Web page on the Web is actually really complex,
>> you have to do a lot of stuff with the header, maybe content-negociate etc.
>> Yet, little kids and grandmothers can jump from webpages to webpages.
> 
> Apparently Ian achieved his example on Apache by simply dropping in
> toucan.rdf and letting apache handle the rest with +MultiViews
> 
> mike@foobar:~$ curl -v http://iandavis.com/2010/303/toucan
>> GET /2010/303/toucan HTTP/1.1
>>
> < HTTP/1.1 200 OK
> < Server: Apache/2.2.8 (Ubuntu)
> < Content-Location: toucan.rdf
> 

Mike, that's the normal pattern for deploy #frag based linked data, 
stick it all in files, then Options +MultiViews to enable conneg.

The main difference here is that HTTP denotes some meaning over all 
representations with status codes (its in HTTPs domain), other than 303 
which cancels that and let's us say something is what we say it is.

However, frag URIs completely skirt around and void this issue, you can 
whatever code you like with them, as they aren't the URIs you GET. 
Whereas </slash> does not.

Many have been doing the frag approach successfully and simply with zero 
issues and staying clear of HTTP semantics while getting the benefit for 
years by using frag URIs.

Best,

Nathan

Received on Friday, 5 November 2010 18:24:47 UTC