Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> 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
> 
> 

Kendall,

Thnaks for finding that extract - it certainly helps me. Given that faults are 
an open set, then we just need to be sure that the language of the SPARQL 
protocol is not providing a stronger condition.  It does do that for 
QueryRequestRefused where it places a "must" requirment (MalformedQuery only 
uses "should").

	Andy

Received on Tuesday, 10 January 2006 13:23:13 UTC