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

Hi,

On 27 April 2011 11:18, Alexander Dutton <alexander.dutton@oucs.ox.ac.uk> wrote:
> 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?)

+1 to using the full range of HTTP status codes.

Personally I don't really see it as see it as revisionist or
retro-fitting to use HTTP status codes to indicate these application
level semantics. There's a good range of status codes available and
they're reasonably well defined for these broad scenarios, IMO.
Especially so when you use additional headers, e.g. Retry-After (as
David Booth noted) to communicate additional information at the
protocol level.

This is mainly about good web application engineering that anything to
do with SPARQL protocol per se.

However it may be useful to define a standard response format and
potentially error messages to help client apps/users distinguish
between more fine-grained error states. I suggested this during
discussion of the original protocol specification but the WG decided
it wasn't warranted initially [1]. Based on this discussion I'm not
sure implementation experience has moved on enough, or converged
enough to feed this back as part of SPARQL 1.1.

Doesn't stop the community agreeing on some conventions/best practices though.

Cheers,

L.

[1]. http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jan/0106.html

-- 
Leigh Dodds
Programme Manager, Talis Platform
Mobile: 07850 928381
http://kasabi.com
http://talis.com

Talis Systems Ltd
43 Temple Row
Birmingham
B2 5LS

Received on Thursday, 28 April 2011 10:27:17 UTC