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

Hi Andy,
Thanks, interesting ways of putting it, and moves the focus slightly, so I could put it this way (sort of!).
5xx is the server can't do what you want, and there isn't much point in the client having another go with the same request.
However, as you say, it may be that the server could perform the request at another time.
And it is actually arguable that the client is wrong if it asks for things like ?s ?p ?o on a large store :-)

I would not presume to suggest what should happen in detail, as there has been much thought on this.
But I would like to reiterate that as a client it should be possible to distinguish useful responses (the responses are for the benefit of the client, not the server).

I am looking at things from the client's point of view, in terms of actionable information.
In practice, what I currently do is not good, but it is constrained by the 500 given back.
If I get a 500, I might send the same request a couple of more times, to see if it is a server overload problem (sorry!).
Then I might try to simplify the query, LIMIT, split it, or whatever.
Then I might check I have an actual valid endpoint, and that I am invoking it in the right way, as best I can, for example by sending some simple queries.
(I might even check the sparql syntax - I should get a 400 if it is a syntax error, but I am not sure that is what all endpoints do - and I know one that does a 200.)

If after all that I get nothing but 500, then I can assume what?
If I have successfully got something out of this endpoint before, then I am guessing that Apache can't connect to the back end cluster, or whatever.
Otherwise, I sort of don't know much.

Somehow I think that the codes should enable me to distinguish between these, as each of them implies that the client should take different actions to compensate.
And it is in the server's interest to do so, as otherwise I will start firing off stuff to investigate.

Best
Hugh

On 17 Apr 2011, at 21:32, Andy Seaborne wrote:

> To quote RFC 2616:
> 
> """
> Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request"
> """
> 
> and the server is incapable.  It may be the query or the given query at that point in time.
> 
> There aren't that many HTTP status codes defined and fitting "server refuses, but your request was valid" to 500 seems close, just not very near.
> 
> A server can (and should?) use any appropriate HTTP code.  503 "Service Unavailable" looks useful here but it notes:
> 
> """
>      Note: The existence of the 503 status code does not imply that a
>      server must use it when becoming overloaded. Some servers may wish
>      to simply refuse the connection.
> """
> 
> The 4xx's means the client is wrong. query timeouts may be due to many things, like concurrent requests from other clients, so it's not simply a mistake by the client. In SPARQL protocol terms, the query request is valid (it's a legal query).
> 
> 	Andy
> 
> 
> On 17/04/11 21:07, Hugh Glaser wrote:
>> Ah, thanks.
>> That explains it.
>> I was puzzled why I was getting 500.
>> I assumed the endpoint was returning 500 by mistake.
>> Never crossed my mind it might be the the "correct" thing to do.
>> 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.
>> Best
>> Hugh
>> 
>> ----- Reply message -----
>> From: "Alexander Dutton"<alexander.dutton@oucs.ox.ac.uk>
>> To: "public-lod"<public-lod@w3.org>
>> Subject: Why does rdf-sparql-protocol say to return 500 when refusing a query?
>> Date: Sun, Apr 17, 2011 06:04
>> 
>> 
>> 
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Hi all,
>> 
>> The SPARQL Protocol for RDF specification¹ say sin §2.2 that
>> "QueryRequestRefused [is] bound to HTTP status code 500 Internal
>> Server Error", and should be used "when a client submits a request
>> that the service refuses to process". The HTTP 1.1 specification²
>> states that a status code of 500 means that "the server encountered an
>> unexpected condition which prevented it from fulfilling the request".
>> 
>> A server might reasonably expect that it will receive
>> resource-intensive requests, and respond to those by declining to
>> fulfil them. It is not a client error, not a server error, as the
>> client is being overly demanding. As such, a 500 response seems — to
>> me, at least — inappropriate.
>> 
>> The SPARQL protocol spec also says in §2.1.4 that "the
>> |QueryRequestRefused| fault message [does not] constrain a conformant
>> SPARQL service
>> <http://www.w3.org/TR/rdf-sparql-protocol/#conformant-sparql-protocol-service>
>> from returning other HTTP status codes or HTTP headers as appropriate
>> given the semantics of HTTP". Does this contradict §2.2, and the WSDL
>> definition?
>> 
>> I've heard a rumour that one or more implementations return a 509. To
>> me, a 403 seems somewhat appropriate (but isn't perfect). What do
>> other people think, and what is currently implemented?
>> 
>> Yours,
>> 
>> Alex
>> 
>> 
>> ¹<http://www.w3.org/TR/rdf-sparql-protocol/>
>> ²<http://tools.ietf.org/html/rfc2616#page-70>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>> 
>> iEYEARECAAYFAk2qc50ACgkQS0pRIabRbjCV7QCfcxy/K8dvGtDA8CA3egRaaqfD
>> 8swAn1D/aMUEdTfI/hgVv5UEo7f7vwlr
>> =CVKO
>> -----END PGP SIGNATURE-----
>> 
>> 
>> 
> 

-- 
Hugh Glaser,  
              Intelligence, Agents, Multimedia
              School of Electronics and Computer Science,
              University of Southampton,
              Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 78 9422 3822, Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

Received on Wednesday, 27 April 2011 09:14:46 UTC