Re: HTTP Status Codes for QueryRequestRefused

On Jan 11, 2006, at 11:02 AM, Steve Harris wrote:

>
> On Wed, Jan 11, 2006 at 10:38:38AM -0500, Kendall Clark wrote:
>> My other suggestion was just to drop this WSDL fault completely. I've
>> convinced myself that it's pretty useless and unnecessary.
>
> That seems sensible to me, it's not clear what a generic WSDL handling
> thing would make of it anyway.

WSDL faults are *application level* faults. So in my service I would  
return QueryRequestRefused by returning HTTP 500 *plus* some fault- 
details explaining in plain language *why* I returned it. I'd have  
some policy stuff in there about how I won't retrieve graphs that are  
larger than 100mb or how after doing query analysis, the query  
submitted was too expensive to process *right now*, since load is  
heavy, or etc. If I could distinguish programmatically, I'd include  
in the fault-details whether there was any point in resubmitting an  
identical request at a future time.

If I just have a misconfigured Apache, then Apache will return the  
500 -- as you rightly suggest -- and that's *not* an application- 
level fault (as you also rightly conclude),  and it's message body  
will include the generic Apache blah blah about misconfigurement, not  
a bunch of application specific policy glop.

Any HTTP status codes other than 400 or 500 are *not* WSDL faults.  
(This is one reason I chose 400 and 500, rather than more specific  
and more often used HTTP status codes.)

Anything that isn't 400 or 500 is *merely* an HTTP status codes and  
means whatever that RFC says it means. In the case of 400 or 500 you  
can't always *necessarily* distinguish the WSDL fault from the HTTP  
status code, because overloading can cause ambiguity, but that  
doesn't mean you can *never* distinguish them. As the spec says, our  
WSDL faults *should* contain fault-details. When they do, then  
someone (though perhaps not always a machine) will be able to  
distinguish them.

The real way to solve *this* problem (if it is a problem) is to make  
the inclusion of fault-details a *must* instead of a *should*. And  
also, to ensure machine-readability, specify a machine-readable  
representation of those fault details, at whatever granularity or  
expressivity floats the majority of our boats.

Cheers,
Kendall

Received on Wednesday, 11 January 2006 16:13:50 UTC