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

This might be a completely dumb idea but what about including some rdf in the response body giving a more detailed explanation of the problem?

"Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method."


-----Original Message-----
From: public-lod-request@w3.org [mailto:public-lod-request@w3.org] On Behalf Of Andy Seaborne
Sent: Wednesday, April 27, 2011 5:35 AM
To: Hugh Glaser
Cc: <public-lod@w3.org>
Subject: Re: Why does rdf-sparql-protocol say to return 500 when refusing a query?


I agree with the sentiment.  Teh HTTP status codes jist aren't up to 
this sort of work, they come from a background of accessing HTML pages 
by browsers.  They just don't capture resource-intensive requests very 
well IMHO so pushing on the boundaries of HTTP status codes isn't going 
to be easy.

Unrelated example:
Using 303 in httpRange-14 is a bit weird because:

"""
This method exists primarily to allow the output of a POST-activated 
script to redirect the user agent to a selected resource.
"""
so the original purpose is quite clear, and nothing to do with all the 
IR/NIR games which are pushing heavily on the next sentence:
"""
The new URI is not a substitute reference for the originally requested 
resource.
"""


Using 4xx for something that the client should fix at the protocol level 
(syntax error) and 5xx for something that isn't completely in its 
control is the best there is.  Changing the query is much like asking 
for a different web page (in HTTP terms it is asking for a different 
resource - the URL has changed).

Maybe the standard text for 500 should be:

500 - please don't try that again.

:-)

A good ping query is "ASK{}"

 > If after all that I get nothing but 500, then I can assume what?

Nothing - there isn't the variety of language in HTTP status codes to 
express the possibilities, even if the server knows anything.  If it's 
under load, the load may going away in the next second, or may not.

What you want is probably a set of HTTP status codes that are covering 
the ins-and-outs of request-response of the characteristics of query 
execution.

 > (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.)

Tut, tut.  That case is very clear.

	Andy

On 27/04/11 10:14, Hugh Glaser wrote:
> 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-----
>>>
>>>
>>>
>>
>

Received on Wednesday, 4 May 2011 15:48:17 UTC