[TAP] draft 0.42 - errors

[Francois Ochsenbein]

Hi Paul,

It would be very difficult to make use of the HTTP convention codes,
this was already noted in one of the first version of TAP years ago
(by Aurelien Stebe and Pedro Osuna if I remember correctly);
at that time it was already noted that the protocol should be
independant of HTTP. 

400 for instance says "malformed syntax" but this applies to
HTTP syntax (e.g. forbidden characters in the query string).
I see hardly this being applied because the table named in 
a TAP query doesn't exist in the specific database being queried,
because details about this kind of errors have to be provided
to the application in a processable way.

Cheers, francois

>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
>
>
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================