Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> 
> On Jan 6, 2006, at 2:09 PM, Seaborne, Andy wrote:
> 
>> Mine is that the protocol document says a QueryRequestRefused  *must* 
>> be returned and that "*must*" is an absolute requirement  (using 
>> RFC2119 terminolgy).  That leaves no room to return another  status 
>> code and claim to be an implementation of the SPARQL interface.
> 
> 
> There are conditions under which that is the *WSDL fault* to return.  
> which has nothing whatever to do with any HTTP status code that isn't  
> *serializing* a fault.
> 
> RFC 2119 terminology doesn't control WSDL or its interaction with the  
> HTTP spec.

I was framing my concern in terms of the text in the SPARQL protocol doc.

1/ The doc says QueryRequestRefused "*must*" be returned when a server refuses 
a request.

2/ "*must*" is as in RFC 2119 - there's no choices

3/ QueryRequestRefused is encoded as HTTP status 500

But there is only one status code in an HTTP response and there must be one.
Servers and clients have to agree on the interpretation of the concrete status 
code.

A successful request gets a 200 (or something from 2xx).
A bad request gets 400.

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.

Best would be to say that QueryRequestRefused is any status code in 4xx and 
5xx except for 400 but WSDL can't express that (can it?).  Or allow other 
faults we haven't defined to be returned.

If we said "*should* be returned", [2119/meaning: the full implications must 
be understood and carefully weighed before choosing a different course] then 
that would work.

> 
>>> If you want a statement to that effect in the document, I drafted  
>>> one  in my previous message. You reject it because you think it   
>>> contradicts "intended interaction". But it doesn't.
>>
>>
>> If that is:
>>
>> "A SPARQL Protocol service may employ the full range of HTTP status
>> codes consistent with the usage of QueryRequestRefused and
>> MalformedQuery as describe in section 2.1.4."
> 
> 
> Nope, that wasn't an offer, for reasons I explained clearly. (Why are  
> we singling out HTTP status codes? Why not HTTP headers too?)

Because HTTP status codes are used to tranfer WSDL faults and there is only 
one status code per request.  The other headers are not overloaded in this way 
- thay are not mentioned by the general mapping of WSDL to HTTP nor in our 
specific example.

A complication is that HTTP status codes may come from intermediate elements 
(if the service were a CGI script, then you get a regular 403 when it is not 
accessible to the web server - also the gateway 502 example).

> 
> Cheers,
> Kendall
> 
	Andy

Received on Friday, 6 January 2006 20:41:21 UTC