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

Not dumb at all - it would be a good idea to include something in 
addition to the status code.  Agreeing what exactly has been tricky.

In the case of a SELECT query, however, there is a wrinkle that the 
client may not have an RDF parser - the results (if the query worked) 
are not RDF so an RDF parser for just errors is a bit of a burden.

	Andy

On 04/05/11 16:13, Whitley, Zachary C. wrote:
> 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 16:39:06 UTC