W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: protocol 1.1 review (to 2.3)

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Sun, 07 Aug 2011 15:57:17 -0400
Message-ID: <4E3EEE1D.70906@thefigtrees.net>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg@w3.org
On 8/7/2011 2:41 PM, Andy Seaborne wrote:
>
>
> On 07/08/11 18:15, Lee Feigenbaum wrote:
>>> 4xx is client error.
>>>
>>> Supplying a datasets description to a service endpoint that does support
>>> a dataset description is a client error (this is SPARQL 1.0
>>> protocol-ness) not a server error.
>>
>> I have to squint pretty hard to see it as a client error, actually.
>> But I don't feel that strongly, anyway :)
>
> I think it's a client error because the service description (directly or
> indirectly by some langauge description of the service or other
> contract) says "I do ABC" so requests for anything else are a client error.

I don't buy this line of reasoning. If I advertise that my service can 
only run queries that with a certain level of complexity, and a client 
submits a more complex query than I'm willing to run, I'd still expect 
that that causes a 5xx error.

>>> 400 is more just parse error. "malformed request" is the best we can do
>>> for request mistakes the client.
>>
>> HTTP defines this pretty clearly:
>>
>> """
>> The request could not be understood by the server due to malformed
>> syntax.
>> """
>>
>> ...so I really think 400 is _just_ syntax.
>
> yes, but, as per last WG, what client error do you suggest?
>
> On the surface several 4xx look like possibilities but the detailed
> description does nor fit. We were left with "it's the client's fault ->
> 400" in absence of a perfect choice.
>
>> HTTP introduces 5xx error codes this way:
>>
>> """
>> 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.
>> """
>>
>> To me, the case in question (supplying a dataset description to a
>> service endpoint that won't take one) is a case of the server being
>> aware that it is incapable of performing the request.
>
> As is the client!

Well sure, but the specification says that this is a 5xx error.

> 500 => The server encountered an unexpected condition
>
> It's not unexpected! (But pushing the text on HTTP status codes is
> unwise anyway. They just were designed for application errors.)

Sure it's unexpected. The server expected that clients wouldn't be 
trying to throw datasets at it. I think 500 fits this situation very well.

> This is not new to SPARQL 1.1 - what do deployed systems do?
>
> Joseki has always returned 400 in this case.

I don't know what other systems do.

Lee

>
> Andy
>
>
>
>
Received on Sunday, 7 August 2011 19:58:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT