Re: Why does rdf-sparql-protocol say to return 500 when refusing a query?

On 17/04/11 21:07, Hugh Glaser wrote:
> As a consumer I would like to be able to distinguish a refusal to answer from a failure of the web server to access the store, for example.

In the general case, that was my concern, too. AFAICT from the spec, you 
aren't precluded from returning e.g. 504 if the store has disappeared.


I've always (perhaps wrongly) equated a 500 with the web server 
encountering some exceptional and *unexpected* condition¹; specifically, 
an uncaught exception in the web application. As such I've always taken 
a 500 to be indicative of a bug which should be fixed to fail more 
gracefully, perhaps with a more appropriate code from the 4xx/5xx range².

As a web developer I always try to 'fix' situations where my code 
returns a 500. As a consumer I will take a 500 to be an application 
error and attempt to inform the webmaster of the inferred 'bug'.


I can think of the following situations where a SPARQL endpoint might 
not return a result:

* Syntax error (400)
* Accept range mismatch (406)
* Query rejected off-hand as too resource-intensive (403?)
* Store unreachable (504?)
* Server overloaded (503?)
* Query timed out (504?, 403?)

Distinguishing the last two server-side could well be difficult — how do 
I know whether the query would have completed had other queries not been 
happening? — but the client response should be quite different. If 
overloaded, try again later; if timed out, try something simpler. The 
latter also goes for off-hand rejection, and it could well be argued 
that these conditions should be indistinguishable client-side.


I agree with Andy that trying to retrofit these semantics onto HTTP 
status codes is never going to be pretty, but I do think it would be 
advantageous to specify how endpoints can be more expressive in 
reporting errors.


All the best,

Alex



¹ It can be expected that someone might submit a resource-intensive 
query, or that the service might be otherwise overloaded.
² For example, if falling over on bad user input then add better input 
validation and return a 400; if some dependency is unavailable then a 
503 or 504.

Received on Wednesday, 27 April 2011 10:18:58 UTC