- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Mon, 24 Oct 2005 11:05:02 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: Steve Harris <S.W.Harris@ecs.soton.ac.uk>, public-rdf-dawg@w3.org
On 15:40, Mon 24 Oct 05, Seaborne, Andy wrote: > That's better - the question is who's made the mistake in this situation. I don't believe that's the question *in general*, since there are cases where QueryRequestRefused will be returned where there is no error at all: This fault message must be returned when a client submits a request that the server is unable or unwilling to process, perhaps because of resource consumption or other policy considerations. The QueryRequestRefused fault message does not indicate whether the server may or may not process a subsequent, identical request or requests. > 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. In my first protocol draft, I tried to define several SPARQL errors or warnings or conditions, mapping them to HTTP return codes. That seemed not to get WG consensus, so we swerved back to a more minimalist set of 2 conditions only. I think it's reasonable to define a few more. :> Cheers, Kendall -- Sad songs and waltzes aren't selling this year... --Cake
Received on Monday, 24 October 2005 15:07:32 UTC