Re: A question - use 301 instead of 406?

Hi again,

thinking twice about my answer...

If you follow my suggestion, for example, to the query

  GET /foo.html HTTP/1.1
  Accept: text/turtle

you would answer

  HTTP/1.1 406 Not acceptable
  Content-type: text/turtle

  @prefix : <http://example.com/some_vocab> .
  </foo.html> :represents </foo> ;
              :has_mimetype "text/html" .

  </foo.ttl> :represents </foo> ;
             :has_mimetype "text/turtle" .

from which the agent could decide what to do.

However, what is the turtle above if not a representation of the
resource identified by /foo.html?
So in that case, the status code should (or at least could) be 200
rather than 406, right?
:-)

I guess this is because of that hypdrid status of RDF (regardless of its
serialization), being somewhere between data and metadata.

  pa



On 24/03/2010 09:06, Pierre-Antoine Champin wrote:
> Hi Hugh,
> 
> interesting suggestion; I have also been frustrated with dbpedia URIs in
> the adress bar, which you have to (or forget to) change when you want to
> feed them to an RDF agent...
> 
> However, 406 seems to be the most appropriate answer to give. Falling
> back to 301 in too many different situations for the sake of forgiveness
> is muddling the waters, IMHO...
> 
> I propose a middle way: the HTTP RFC [1] reads, regarding 406 responses:
> 
>> Unless it was a HEAD request, the response SHOULD include an entity
>> containing a list of available entity characteristics and location(s)
>> from which the user or user agent can choose the one most
>> appropriate.
> 
> As a matter of fact, http://www.w3.org/ complies with this
> recommandation (try to request it for image/svg, for example). It gives
> you a page with alternative representations.
> 
> I think this would be a good principle for linked data as well, as
> linked data relies heavily on Conneg. Note that if you request RDF for
> http://foo/bar.html, the server could reply with 406, but include an
> entity in RDF explaining where you can find other representations...
> Your agent could then interpret that and fetch the new URI.
> 
>   pa
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7
> 
> 
> 
> On 23/03/2010 23:50, Hugh Glaser wrote:
>> I am not sure I even dare ask this, but here goes. (This is prompted
>> by a real application implementation - it is not just a 
>> hypothetical.)
>>
>> Assuming that we are in the usual situation of http://foo/bar doing a
>> 303 to http://foo/bar.rdf when it gets a Accept: application/rdf+xml
>> http://foo/bar what should a server do when it gets a request for 
>> Accept: application/rdf+xml http://foo/bar.html ?
>>
>> OK, the answer is 406.
>>
>> But is this compatible with the principle of being as forgiving as
>> possible as a server?
>>
>> I think it is clear what the agent wanted: Accept:
>> application/rdf+xml http://foo/bar it is just that somehow the wrong
>> URI got into the system.
>>
>> I know I have made the mistake of for example copying a dbpedia URI
>> from the address bar when I was looking for the LD URI, and ended up
>> wondering for a moment why Accept: application/rdf+xml
>> http://dbpedia.org/page/Tim_Berners-Lee gives me a 406 before I
>> remember I need to right click on the About and copy the link.
>>
>> That's OK if all that happens is I use the wrong URI straight away. 
>> But what happens if I then enter it into a form that requires a LD
>> URI, and then perhaps goes into a DB, and becomes a small part of a
>> later process? Simply put, the process will fail maybe years later,
>> and the possibility and knowledge to fix it will be long gone.
>>
>> Maybe the form validation is substandard, but I can see this as a
>> situation that will recur a lot, because the root cause is that the
>> address bar URI changes from the NIR URI. And most html pages do not
>> have links to the NIR of the page you are on - I am even told that it
>> is bad practice to make the main label of the page a link to itself -
>> wikipedia certainly doesn't, although it is available as the
>> "article" tab, which is not the normal thing of a page. SO in a world
>> where wikipedia itself became LD, it would not be clear to someone
>> who wanted the NIR URI where to find it.
>>
>> So that is some of the context and motivation. If we were to decide
>> to be more forgiving, what might be done? How about using 301? 
>> <<Ducks>> To save you looking it up, I have appended the RFC2616
>> section to this email. That is Accept: application/rdf+xml
>> http://foo/bar.html Should 301 to http://foo/bar It seems to me that
>> it is basically doing what is required - it gives the client the
>> expected access, while telling it (if it wants to hear) that it 
>> should correct the mistake. One worry (as Danius Michaelides pointed
>> out to me) is that the caching may need careful consideration -
>> should the response indicate that it is not cacheable, or is that not
>> necessary?
>>
>> So that's about it. I am unhappy that users doing the obvious thing
>> might get frustrated trying to find the URIs for heir Things, so
>> really want a solution that is not just 406. Are there other ways of
>> being nice to users, without putting a serious burden on the client
>> software?
>>
>> I look forward to the usual helpful and thoughtful responses!
>>
>> By the way, I see no need to 301 to http:/foo/bar if you get a 
>> Accept: text/html http://foo/bar.rdf as the steps to that might lead
>> to this would require someone looking at an rdf document to decide to
>> use it as a NIR, which is much less likely. And the likelihood is
>> that there is an eyeball there to see the problem. But maybe it
>> should?
>>
>> Best Hugh
>>
>>
>> 10.3.2 301 Moved Permanently
>>
>> The requested resource has been assigned a new permanent URI and any 
>> future references to this resource SHOULD use one of the returned 
>> URIs.  Clients with link editing capabilities ought to automatically 
>> re-link references to the Request-URI to one or more of the new 
>> references returned by the server, where possible. This response is 
>> cacheable unless indicated otherwise.
>>
>> The new permanent URI SHOULD be given by the Location field in the 
>> response. Unless the request method was HEAD, the entity of the 
>> response SHOULD contain a short hypertext note with a hyperlink to 
>> the new URI(s).
>>
>> If the 301 status code is received in response to a request other 
>> than GET or HEAD, the user agent MUST NOT automatically redirect the 
>> request unless it can be confirmed by the user, since this might 
>> change the conditions under which the request was issued.
>>
>> Note: When automatically redirecting a POST request after receiving a
>> 301 status code, some existing HTTP/1.0 user agents will erroneously
>> change it into a GET request.
>>
>>
> 
>

Received on Wednesday, 24 March 2010 09:37:47 UTC