W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: HTTP Status Codes for QueryRequestRefused

From: Kendall Clark <kendall@monkeyfist.com>
Date: Mon, 9 Jan 2006 13:53:50 -0500
Message-Id: <6CADF557-C21F-419D-996F-7BB515CC7706@monkeyfist.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: "Seaborne, Andy" <andy.seaborne@hp.com>


On Jan 6, 2006, at 3:41 PM, Seaborne, Andy wrote:

> So if a server sends back 403, it isn't a success.  It isn't  
> MalformedQuery or QueryRequestRefused either so it isn't part of  
> the SPARQL interface.  My implementation experience is that status  
> codes other than 200, 400 and 500 arise when using common  
> deployment platforms.  My proposal is to (for HTTP) state  
> explicitly that other status codes can be used in a SPARQL interface.

Quoting from the CR version of WSDL 2.0 Part 1: Core Language:

Faults other than the ones described in the Interface component may  
also be generated at run-time, i.e. faults are an open set. The  
Interface component describes faults that have application level  
semantics, i.e. that the client or service is expected to handle, and  
potentially recover from, as part of the application processing  
logic. For example, an Interface component that accepts a credit card  
number may describe faults that indicate the credit card number is  
invalid, has been reported stolen, or has expired. The Interface  
component does not describe general system faults such as network  
failures, out of memory conditions, out of disk space conditions,  
invalid message formats, etc., although these faults may be generated  
as part of the message exchange. Such general system faults can  
reasonably be expected to occur in any message exchange and  
explicitly describing them in an Interface component is therefore  
uninformative.

Cheers,
Kendall
Received on Monday, 9 January 2006 18:53:58 GMT

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