[TAP] draft 0.42 - errors

[Patrick Dowler]

On Wednesday 29 April 2009 03:50:01 Paul Harrison wrote:
> 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 can degrade into a philosophical debate, so let's be careful :-)

2.7.4 does mention use of 401, 403, and 404 in some cases (the latter should 
also include accessing any non-existent child resources). But your main point 
is about 400 and VOTable error documents...

> 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"

In Section 2.9 (Use of VOTable) there is only one mention of the correct 
mimetype for VOTable (text/xml;content=x-votable) - -whether that is the 
correct mimetype for VOTable is a separate issue, but there is only one used 
here. It is true that 2.7.4 suggests an alternate mimetype to signal errors, 
which I think should be removed.

> 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  

This would in some sense accomplish both goals: status code and VOTable with 
specified error description.

Now for the philosophical part: whether or not it is a good idea (and how 
much) to blend http and TAP behaviour (e.g. make full use of http status 
codes) depends on whether one wants to keep TAP somewhat/mostly/entirely 
transport-agnostic. Practically speaking, to make it entirely transport 
agnostic means we have to write two specs: one for TAP and one for the REST 
bindings (maybe in one document). Right now they are somewhat intertwined and 
untangling them would not be that simple just by virtue of having to come up 
with abstract names for more things. 

Is it worth it to do that? Only if we intend to and actually develop a non-
http TAP specification (and as it stands right now, a non-REST spec: even a 
SOAP bindings would require some work untangling things). In my opinion, I 
don't think that will happen any time soon (eg years), we have plenty to do 
already, and as primitive as HTTP is I don't see anything else out there that 
could get the necessary adoption. That's just my opinion...

Q. Anyone have an argument against errors using a 400 http status code AND 
returning a VOTable for "bad requests"? And by implication, use of other http 
4xx status codes? That is, change 2.7.4 to allow 400. From the client side, it 
is always a case of checking status code and then opening/reading the content 
(or not) and the content would still be the VOTable as described in 2.9

Thoughts?

PS-One complexity is that streaming output could give 200, leading INFO with 
QUERY_STATUS of OK, some content, and then a trailing INFO element describing 
an ERROR status. In such a case the mimetype (and the status code) would not 
agree with the actual result. It's a subtle case and maybe not important, but 
http cannot correctly describe that and clients will have to get the final 
status from the content.

-- 

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/20090429/d3431f7c/attachment-0003.html>