Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> On Jan 5, 2006, at 6:39 AM, Seaborne, Andy wrote:
> 
> 
>>
>>
>>Kendall Clark wrote:
>>
>>>On Nov 1, 2005, at 2:40 PM, Leigh Dodds wrote:
>>>
>>>>These are quite different failure modes and it would be useful to be
>>>>able to distinguish between them. Without that facility a client   
>>>>cannot
>>>>legitimately know whether it can retry its request, or for how long
>>>>the server may be unavailable.
>>>
>>>I think the WG was aware of these implications of choosing only a   
>>>single fault and overloading it for different conditions. There's  
>>>not  been any interest in defining additional faults and  
>>>serializing them  with different HTTP codes as you suggest.
>>
>>There has been interest, from me at least.
> 
> 
> I've only ever heard you say that the QueryRequestRefused fault  
> should be serialized with a different HTTP code than the one I think  
> it should be serialized with. That's similar but not the same point I  
> made to Leigh. FWIW.
> 
> 
>>We could say that this is an HTTP-level fault, it does not need to  
>>be reflected at the SPARQL level (so does not need to be reflected  
>>in the protocol document).  But the document and your reply suggest  
>>otherwise. Better to accept it will happen.
> 
> 
> Yes, because that's the design I thought we had consented to. If  
> not,  I'm happy to change the doc to reflect the new design.
> 
> But it'll have to be put onto the agenda or something, because I only  
> know today that I don't believe I agree with this analysis and you do  
> agree with it, so that doesn't seem like enough consensus to change  
> the doc.
> 
> 
>>If we add a paragraph with 2.2 saying that other HTTP faults must  
>>be handled by the HTTP layer, then we reflect the fact that such  
>>codes can occur and must be dealt with in the usual way for the  
>>implmentation environment (without having to say what the usual way  
>>is).
> 
> 
> I don't see how adding this language actually *adds* anything  
> whatever to the spec. That is, it's the same design whether this text  
> is there explicitly or not (or so I claim), because this position is  
> the default. There's no language anywhere saying that other HTTP  
> status codes should not or must not be returned or that, if they are  
> returned, they should not or must be "dealt with in the usual way".  
> The document is, as I've pointed out to David Wood and Leigh Dodds  
> lately, silent on what else might or may happen.
> 
> Anyway, my 2 cents, but I haven't see enough consensus or support to  
> warrant changing the doc yet. :>
> 
> Cheers,
> Kendall

I would like to see some text that states that it is possible for the HTTP 
request to rturn other (HTTP related) codes because it is outside the defined 
WSDL.

	Andy

Received on Thursday, 5 January 2006 15:43:52 UTC