[TAP] draft 0.42 - errors

[Guy Rixon]

Pat et al.,

the alternate MIME-type for error-documents was suggested in order  
that we keep VOTable
as a format for the error documents. In the case of a workflow system,  
it is convenient
to detect errors without having to parse the output . We can either do  
this through HTTP
codes or through MIME type. I'd prefer to use the HTTP code, as I  
stated last year, but if
we don't use those for TAP errors we still need the special MIME-type.

Cheers,
Guy


On 29 Apr 2009, at 18:15, Patrick Dowler wrote:

> 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/20090430/122202af/attachment-0003.html>