[TAP] draft 0.42 - errors

[Doug Tody]

Hi -

The key issue here is the separation of the application and transport
protocols.  It might make sense for a service to define a more rich
set of error codes to more formally characterize errors, but if we did
so these should be specific to the logical functioning of the service,
and would be visible to a client application, part of the application
service interface, remaining the same regardless of the transport used.

However...  We have managed to do without this level of error
characterization for several years now, and no clear need has been
seen to characterize errors more finely.  Our experience thus far
indicates that just having a few things like ERROR and OVERFLOW,
with an associated free format error string, is enough.  If we did
decide to more fully characterize errors that could be done in a
later version in a backwards compatible sense, by keeping status=ERROR
and adding an additional error code, probably as part of the VOTable
status response to ensure that the information gets through to the
client and that the function of the transport is not compromised.
(This is all reminiscent of Unix where we have an overall status=(0|-1)
and a finer grained errno).

We would not want to do this using an HTTP status code as the generic
HTTP codes are inadequate to describe service-specific functionality
(as already discussed), and use of exotic HTTP status codes to
attempt to describe application functionality might interfere with
the function of the HTTP transport.  I would be concerned for example
that the VOTable status message might never make it through the lower
level layers (browser, wget, custom code, whatever) to the client
application or user.

While Paul is probably right that thus far the DAL protocols have not
said much about what HTTP status to return, this was an oversight
and the assumption all along has been that it would be 200 OK for
normal operation of the protocol, even if a logical service error
condition occurs.  Barring a HTTP-level error, applications never see
the HTTP status at all, they only see the logical protocol status
returned in the VOTable status return.  Anything else such as a
HTTP redirect would be handled at the level of the HTTP transport,
transparent to the application.

> Given that, can we resolve this by removing the explicit requirement for
> 200 so TAP is like other DAL services?

Possibly, as this would be consistent with the current situation with
the other services, and could avoid the problem for now.  My preference
would be to be more explicit and specify 200 OK since this represents
current practice and is what was always intended.  But if you want to
merely delete the 200 OK reference that would be ok.

 	- Doug


On Thu, 30 Apr 2009, Patrick Dowler wrote:

> 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... :-)
>
>