W3C home > Mailing lists > Public > public-lod@w3.org > April 2011

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sun, 17 Apr 2011 21:32:55 +0100
Message-ID: <4DAB4E77.6040703@epimorphics.com>
To: public-lod@w3.org
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 Sunday, 17 April 2011 20:33:38 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:32 UTC