[TAP] draft 0.42 - errors

[Paul Harrison]

On 2009-04 -29, at 23:02, Doug Tody wrote:

> On Wed, 29 Apr 2009, Paul Harrison wrote:
>
>> I think that the signalling of errors as specified in section 2.7.4  
>> in TAP is rather perverse to say the least, as it does not follow  
>> normal HTTP conventions (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 
>> ). The idea that a status 200 OK message should be returned when  
>> there is a TAP error, means that it is much more difficult to write  
>> simple clients that can make a decision about success or failure by  
>> examining a single return value - i.e. the HTTP return status. The  
>> justification for always returning http status 200 (OK) even in the  
>> case of an error seems to be that there is no "error in the HTTP  
>> protocol" - however, the HTTP status values have various classes,  
>> many of which indicate errors in what HTTP is transporting - e.g.  
>> when you get a 404 response in your browser, it does not mean that  
>> HTTP has "broken", but that that the page that you asked for does  
>> not exist - there is an obvious analogy with TAP errors.
>
> I have to disagree with this Paul.  As Pat points out, we want to
> separate the logical service protocol (TAP) from the transport used
> here (HTTP).  In part this is to permit other transports, such as  
> SOAP,
> or possibly even local area transports (e.g. a desktop message bus) if
> we were to use such a service for data access within a single  
> computer.

Pat also points out hat the current way that all the DAL standards are  
written at the moment does not do this layering - they are all  
intimately tied to HTTP and as such it would be nice if they followed  
HTTP conventions.
>
>
> But the issue is more fundamental than that, as we also have to
> consider application level APIs.  Applications (science applications,
> not necessarily things like webapps) will often not see the HTTP
> level protocol at all, rather they will use some high level API.
> A HTTP-specific error code is meaningless at this level, rather we
> want to know the nature of some service error, e.g., due to a service
> operation failing in some way.  Pat notes that maybe we won't have
> a SOAP interface anytime soon, but we will certainly have high level
> application APIs almost immediately once TAP services are available.
>
> HTTP errors are certainly possible and when they occur, indicate
> an error in the HTTP transport, as you note above.
I noted precisely the opposite - in fact to signal errors in the HTTP  
transport itself you would have to look lower in the TCP/IP stack -  
many HTTP error/status codes concern themselves with what is being  
transported.

>  Logical errors
> in either the service protocol or in the functioning of the service
> cannot however be described adequately merely with HTTP error codes.
I did not say that they could - what I said is that when there is a  
problem in TAP you return the VOTable with the detailed error message  
as the body *and* return an appropriate HTTP error status, so that the  
HTTP layers of the client application code can know that an error has  
occurred.
>
> HTTP has nothing to do with what the service is actually doing.
> For example if an invalid query is posed ("syntax error", "table
> not recognized", etc.) HTTP can say nothing useful about that.

Actually Status 400 (Bad Request) would be highly appropriate in this  
case.

>
> Hence we need to return an error response as part of the logical
> service protocol, noting the specific service error which occurred.
> A small VOTable is used for this.  Although the service operation
> may have failed in such a case, the HTTP link worked fine and the
> service is in fact functioning just fine.

If the service had completely failed in some way then a HTTP 5xx code  
would be appropriate.
>
>
> Finally lets not forget that all the current DAL services already work
> this way, and we want to end up with a consistent set of DAL services.
> The way proposed for handling TAP service errors is the same as in SSA
> (as well as the legacy services), and is part of the DAL2 architecture
> and standard service interface adopted with SSA.  This was based upon
> OpenGIS standards, which also work this way.


Actually SIAP and SCS make no reference to HTTP status values at all  
as far as I can see and even SSAP is not explicit in what status   
should be returned in the case of an SSAP error, but does mention that  
the client should be capable of dealing with HTTP errors in section  
8.10.3, so there is little precedent in this matter. It was the bold  
statement in the TAP draft that HTTP status 200 OK should be returned  
even in the case of a TAP error that drew my attention to this - I can  
program my SIAP, SCS and SSAP services to return an appropriate HTTP  
error status in the case of DAL error and still be compliant with  
those standards.

>

Paul