Re: HTTP Status Codes for QueryRequestRefused

On Jan 11, 2006, at 12:52 PM, Seaborne, Andy wrote:

>> Thus, any 403 returned is  NOT a WSDL fault.
>
> From the SPARQL protocol document, yes.  It seems at odds with the  
> open set but let's stick with that for the moment.

Which *WSDL fault* according to our spec or to any WSDL spec or RFC  
2116 does HTTP 403 serialize?

>> It *cannot* be a WSDL fault. QueryRequestRefused  *is* a WSDL  
>> fault. Thus 403 cannot be a refusal by the service.
>
> That is odd because:

It can be or seem as odd to you as you like. The only relevant point  
is whether it's *true*.

403 cannot be a WSDL-refusal by the service, because there is no WSDL  
fault that 403 could possibly serialize given the spec we have in  
hand. The definition of 403 in HTTP uses the word "refuse". Our spec,  
in defining a completely separate *WSDL fault* uses the word  
"refuse" (a WSDL fault that is distinct from HTTP 403 such that there  
is NO WAY anyone could confuse it with HTTP 403, since one results in  
500 and the other in 403. "403" != "500"). So what?

I'm at a loss to see what you think that proves.

> A/ HTTP 1.1 RFC 2616 says:
>
> """
> 403 Forbidden
>
> The server understood the request, but is refusing to fulfill it.
> """
>
> which uses the term "refuse".
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4

So what? "403" != "500".

> B/ The client can not communicate in the usual HTTP manner the  
> reason for a 'refusal' (this is why I suggested "should", in the  
> RFC 2119 sense).

Don't you mean "server" instead of "client"? And why can't the server  
communicate HTTP 403 in the usual manner? We aren't overloading 403.  
We are only overloading 400 and 500. Yr argument applies to HTTP 400  
and 500, but not to 403 or any other code. And as for distinguishing  
QueryRequestRefused and MalformedQuery from HTTP 500 and 400,  
respectively, I gave a complete discussion of that earlier in my  
reply to Steve.

> If you have a specific definition of "refuse", then please put that  
> definition in the document.

I already have. The "refuse" in QueryRequestRefused is an application- 
level refusal to handle a request, which is the reason we give a  
*WSDL fault* for it. Since we're using WSDL 2.0, and unless we  
explicitly override, our use of WSDL faults mean what WSDL 2.0 says  
they mean, i.e., application-level faults. I've given lots of  
examples of application-level faults.

If you don't like the distinction between application and transport  
here, why don't you just say *that*?

>> Yr systematically confusing situations where natural language   
>> speakers might use the English verb "to refuse"  with situations  
>> where
>> QueryRequestRefused is being returned as a WSDL fault.
>
> This text makes the connection to my reading:

It may make "the connection", but it doesn't make yr reading right or  
sensible. And, FWIW, yr quoting from the latest version, but I've  
already said a few times that I've changed that language. Did you not  
see me say that? If not, then I should have been clearer.

> You said you believed that using the word "should" would change the  
> design.

Yeah, I do, if for no other reason than bolded keywords imply or  
create conformance requirements and "should" != "must".

> Please give an example.

That seems like a different design to me, but Dan said I could change  
the design unilaterally since no WG decision is "locking" this part  
of the design. So I don't think the bit about "design change" is  
really relevant any longer, which you could have inferred from my  
having said I was changing the text.

Kendall Clark

Received on Wednesday, 11 January 2006 19:09:41 UTC