Re: SPARQL 1.1 Protocol: HTTP status code for QueryRequestRefused

Hi Richard,

My sincere apologies for how long it has taken us to respond to your 
comment.

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,
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 Tuesday, 19 June 2012 17:10:36 UTC