- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 20 Jun 2012 11:10:53 +0100
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: public-rdf-dawg-comments@w3.org
Hi Lee, On 19 Jun 2012, at 18:10, Lee Feigenbaum wrote: > The Working Group discussed various approaches to specifying HTTP status codes in both success and failure cases for the SPARQL. Given the variety of usage scenarios considered and the fact that the SPARQL 1.1 Protocol is now specifically specified in terms of HTTP, the group decided to allow SPARQL Protocol endpoints to use any appropriate HTTP status code, as long as the codes used are consistent with the HTTP standard. I believe that this very much lines up with your suggestion. The specification text in question is: > > * http://www.w3.org/TR/sparql11-protocol/#query-success > * http://www.w3.org/TR/sparql11-protocol/#query-failure > * http://www.w3.org/TR/sparql11-protocol/#update-success > * http://www.w3.org/TR/sparql11-protocol/#update-failure > > We would kindly ask you to acknowledge that you are happy with this response, This is very good. Thanks! Best, Richard > Lee > On behalf of the SPARQL WG > > > On 9/29/2010 8:23 AM, Richard Cyganiak wrote: >> This is a comment on the latest SPARQL 1.1 Protocol draft [1]. It concerns an issue that was already present in the SPARQL 1.0 version of the Protocol. >> >> I cannot quite work out what HTTP response code to use in the case of a QueryRequestRefused fault. The obvious place to look for this in the specification would be here: >> >> Section 2.2.1, “HTTP Bindings for SPARQL Query”: >> >>> In each of these bindings, the two faults described in SparqlProtocol interface, MalformedQuery and QueryRequestRefused, are bound to HTTP status codes 400 Bad Request and 500 Internal Server Error, respectively [HTTP]. >> >> The WSDL snippet in this section says the same thing. But elsewhere I find: >> >> Section 2.1.1.3.2, “QueryRequestRefused”: >> >>> The QueryRequestRefusedfault [does not] constrain a conformant SPARQL service from returning other HTTP status codes or HTTP headers as appropriate given the semantics of [HTTP]. >> >> The problem in my eyes is: >> >> 1. The two quotes contradict each other. >> >> 2. Any language about HTTP status codes should be in the HTTP Bindings section, not in the abstract interface definition section. >> >> Hence I propose to remove that sentence from 2.1.1.3.2, and reduce the last sentence of the section to just: >> >> “The QueryRequestRefusedfault message does not indicate whether the server may or may not process a subsequent, identical request or requests.” >> >> Furthermore, I propose to add the following sentence after the sentence starting “In each of these bindings ...” in 2.2.1: >> >> “Despite the use of the 500 status code for QueryRequestRefused in this binding, a conformant SPARQL service MAY return other HTTP status codes or HTTP headers as appropriate given the semantics of [HTTP].” >> >> Best, >> Richard >> >> [1] http://www.w3.org/TR/2010/WD-sparql11-protocol-20100126/ >> > >
Received on Wednesday, 20 June 2012 10:11:27 UTC