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

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

From: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk>
Date: Sun, 17 Apr 2011 12:59:09 +0800
Message-ID: <4DAA739D.4060308@oucs.ox.ac.uk>
To: public-lod <public-lod@w3.org>

-----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 04:59:42 UTC

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