Re: protocol 1.1 review (to 2.3)

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.

>> 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!

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.)

This is not new to SPARQL 1.1 - what do deployed systems do?

Joseki has always returned 400 in this case.

 Andy

Received on Sunday, 7 August 2011 18:42:08 UTC