[TAP] draft 0.42 - errors

[Paul Harrison]

Firstly, can I say that this version of the TAP standard is a vast  
improvement on previous ones (especially if all the stuff with lines  
through gets deleted!).

On 2009-04 -21, at 09:06, Patrick Dowler wrote:


>
> I have just posted TAP 0.42 draft to the DAL WG page:
>
> http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/TableAccess



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.

This version of the document does mention that the error status should  
also be indicated in the mime type of the returned error document -  
presumably in an attempt to allow for simple clients easily to access  
an error condition in exactly the way that the HTTP status is designed  
for.  In fact it could be read that this sort of abuse of mime-types  
is explicitly forbidden by the mime standard http://tools.ietf.org/html/rfc4288#section-4.3 
  - "New parameters SHOULD NOT be defined as a way to introduce new  
functionality in types registered in the standards tree"

Surely it would be better to return an appropriate HTTP status code -  
there is a rich vocabulary of them, e.g. 400 (Bad Request) has an  
obvious applicability -and return the VOTable with the more detailed  
error information as the response body. Then there would be a single  
value that all clients could access to determine quickly the status of  
the TAP response in all circumstances of all TAP operations, as the  
UWS adhering parts of TAP are already using the HTTP status according  
to standard conventions.

Cheers,
	Paul.

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank