[TAP] draft 0.42 - errors

[Patrick Dowler]

On Thursday 30 April 2009 01:58:39 Paul Harrison wrote:
> 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.

First, I will say I am on the fence on this one. I have been burned in the 
past when protocol error handling and application error handling could not be 
sufficiently disambiguated and I am loathe to repeat the experience.

I think it is safe to say that if the TAP doc was written more carefully, 
meaning keeping the service ops and REST binding distinct, we could specify 
http status codes for the REST binding. There is already documented use of 
401, 403, and 404.

I agree with Paul that 400 "Bad Request" seems like a generic http application 
error code: rfc2616 says "request could not be understood by the server due to 
malformed syntax". I don't think that is limited to just URL and/or parameter 
syntax, but also syntax of values of parameters if they have them -- and in 
TAP values have syntax. Francois does pose an odd case where querying a table 
that does not exist is syntactically valid... there are others. 

Practically, if I was writing client software, I would be checking the 
content-type and if it was VOTable I would parse and make all decisions based 
on what I found there. If it was not VOTable, I would check the http status 
code and in some cases might do something different (e.g. 401). I don't see how 
a different status code (in the case 400 and a VOTable) would change this from 
the client perspective (aside from redirects, where you get a 302 or 303, 
content-type, and Location, iirc).

Given that, can we resolve this by removing the explicit requirement for 200 
so TAP is like other DAL services? eg. allowing services to use http status 
codes to provide an extra channel of information if they like, but only 
specifying the required VOTable error response. We already have liberal use of 
http status codes, especially in the UWS-REST-based /async endpoint...

PS-No one has mentioned 402 yet... :-)

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090430/a548a620/attachment-0003.html>