A question - use 301 instead of 406?

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 Tuesday, 23 March 2010 22:51:51 UTC