Re: SPARQL Protocol Test Suite Update

Steve Harris wrote:
> On Mon, Oct 24, 2005 at 09:21:54 -0400, Kendall Clark wrote:
>>On 13:29, Mon 24 Oct 05, Seaborne, Andy wrote:
>>>== "select-refused"
>>>Not sure why the query is to be refused.
>>>I'd return a 400 (BAD REQUEST) if query is sent that the (mythical) service 
>>>description had said it was not supported in some way (e.g. described 
>>>dataset but the service only has a fixed dataset).  It is not a server 
>>>error if the client sends a request the server has said it can't handle.
>>This is *really* a comment against the protocol spec, isn't it? One I've
>>heard from and discussed with Steve a long time ago (well, relatively
>>speaking), and one we discussed during the telcon on IRC last week.
>>I won't repeat that discussion (for the 3rd time) here; suffice to say, for
>>now, I'm not convinced. The 5xx error series is *not* for server "errors"
>>only. The first sentence of 10.5 Server Error 5xx says, quite plainly,
>>"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." I take "unwilling" to be a special case of "incapable". While the
>>spec presently says QueryRequestRefused is to be bound to 500, I'd be happy
>>with it returning 501. 
> 501 is more specific, and so seems better to me.
> - Steve

That's better - the question is who's made the mistake in this situation. 
Client or server.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems 
to have erred.

I think it's the client who has erred (didn't follow the service description)

- - - - - -

A related, but different issue, is what to do about other HTTP return codes 
such as 401 (Unauthorized), 402, 403 -- it would seem appropriate to reflect 
these like any other use of HTTP but, as I read the spec, a compliant service 
should not return unlisted error codes.


Received on Monday, 24 October 2005 14:41:45 UTC