Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> 
> On Jan 10, 2006, at 12:08 PM, Seaborne, Andy wrote:
> 
> 
>>(From the client's point of view, I read "refuse" as covering all  
>>and any circumstances other than a bad request when a service is  
>>not going to execute a request.  "Unable" because of some issue  
>>like local security policy is a refusal).
> 
> 
> Hmm, okay, then that's the bit we need to tweak. I have understood  
> all along -- especially given the other bit which you never quote or  
> seem to acknowledge: "The QueryRequestRefused fault message does not  
> indicate whether the server may or may not process a subsequent,  
> identical request or requests." -- that QueryRequestRefused is for  
> policy refusals, not for anything else.

Of course I acknowledge the bit about subsequent requests - it's about what 
might happen later.  The first sentence still stands.

The concrete example I keep coming back to is the security one.  A security 
refusal is going to the same refusal next time.  Access control is (an 
implementation of) a security policy.

Why is 403 not a refusal to execute the request?  403 requests should not be 
retried.

> In yr example, WSDL faults are an open set, and the usual or ordinary  
> HTTP status code for security issue (403 perhpas?) is perfectly legal  
> to return. Honestly, Andy, let's find some other way

Other than what?  I am just reading the spec and making an interpretation. 
I'm not advocating a design change.  I'm just reading the text and having a 
real hard time sticking to the letter of what it says.  It says "must" when a 
server "refuses".  It should be at least be "should".  And in the language of 
RFC 2119 that would be good because it obligates the service implementer to 
think hard about returning anything other that QueryRequestRefused.

 > to fix this
> because I have no more confidence that I'm going to convince you than  
> you probably have of convincing me. Or, put another way, I'm very  
> unlikely to be convinced of yr position, at least not w/out something  
> new.

It is clear that you will not change the document.

> Would making the "refusal for reasons of policy" more explicit help you?

If you mean:
"""
This fault message must be returned when a client submits a request that the 
service refuses to process for reasons of policy.
"""

then it is not acceptable.

Insert "security policy" (a common piece of terminolgy) and it means 403 is 
ruled out.  The link to "3. Policy Considerations" does not restrict it to 
only those polices or that particular case of "security policy".  Actually, it 
makes it worse, because privacy is one of the policies discussed.

	Andy

> 
> Cheers,
> Kendall
> --
> You're part of the human race
> All of the stars and the outer space
> Part of the system again
> 
> 
>

Received on Tuesday, 10 January 2006 18:02:02 UTC