Re: HTTP Status Codes for QueryRequestRefused

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.

A suggestion: recognize that there are two layers here - the SPARQL/P layer 
and the HTTP "transport".  Then, SPARQL gets to define the SPARQL-layer faults 
and there is an expectation on the HTTP protocol implementation/usage to 
decide what to do.

Example: 502 (Bad Gateway)

This happens with SPARQLer, which is an Apache server, with a backend Jetty 
server for the web application.  It is not an uncommon way of setting thing 
up.  The fault is generated by the Apache server when the Jetty server isn't 
available. The Apache server is being a gateway and is not aware this request 
is a SPARQL one over any other HTTP request.  It can't make a special case of 
SPARQL/P and return a different fault.

This means that SPARQLer can't stricly be a SPARQL query service end-point 
because it might return a different code.

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.

Doc example:
"""
QueryRequestRefused

This fault message *must* be returned when a client submits a request that the 
server is unable or unwilling to process,
"""

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).

	Andy

> 
> 
>>This additional feature could be supported by allowing a choice in
>>response codes:
> 
> 
> Hmm, no, I don't believe that's possible in WSDL. We'd have to define  
> two additional faults.
> 
> 
>>* 503 Service Unavailable, optionally with a Retry-After header, to
>>indicate temporary unavailability and an estimated time after which  
>>the
>>request can be retried
> 
> 
> ServiceUnavailable (or some such), though I'm not sure how to specify  
> the Retry-After header.
> 
> 
>>* 403 Forbidden to refuse abusive requests and indicate that a retry
>>is not permissible.
> 
> 
> As for this, I don't see what it adds as distinct from  
> QueryReqRefused. I mean, I'm not sure you can say that a request is  
> abusive *per se*. It may depend on local conditions and those change.  
> Just not sure.
> 
> Cheers,
> Kendall
> 
> PS--I somehow missed this message when you originally sent it. Sorry  
> I'm so late responding.
> 
>

Received on Thursday, 5 January 2006 11:39:24 UTC