Re: HTTP Status Codes for QueryRequestRefused

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

Received on Thursday, 5 January 2006 14:25:41 UTC