RFC for DALI-1.0

[Patrick Dowler]

The last 2 paragraphs of 4.2 clearly state that an error document is 
returned with a status code of 200 when retrieved from a DALI-async 
error resource aka the UWS /service/joblist/jobid/error resource and 
with a suitable status code if returned directly (eg as part of some 
other call, http or otherwise) which is always the case for DALI-sync 
service invocations. The text in brackests about "4xx or 5xx for HTTP" 
is meant to say that what "suitable" is when the transport protocol is 
http and the last sentence specifically punts on other transport protocols.

So, the intent - as agreed in Sao Paulo - is that you use a suitable 
status code for error documents (and not 200) when the protocol is http.

Pat

PS-The discussion as I recall was that this was going to be better for 
clients when used along with plain text error documents

On 03/14/2013 09:28 AM, Douglas Tody wrote:
> On Thu, 14 Mar 2013, Markus Demleitner wrote:
>>
>> A second major point would be that from the current document I'm
>> still not sure whether I'm supposed to return my VOTable error
>> documents with a 200 or a 400/500/some other error code.  I believe
>> the Sao Paulo agreement was current DAL behaviour (returning 200 if
>> you can even if the server's on fire) would be legal and might be
>> mandatory); I won't veto that, but I'd like to repeat my strong
>> dislike for this kind of weirdness ("everything's ok, but here's an
>> error message for you...").
>
> I think that we should continue to distinguish between errors in the
> transport protocol (HTTP error codes), and errors in the DAL service
> functionality.  Hence returning a HTTP 200 status if things are OK at
> the HTTP level should be permitted if not mandatory for services which
> return a VOTable status document.  If we were to start returning HTTP
> error codes for service logical errors then it is likely that somewhere
> in the HTTP transport layers the error would be caught and the transport
> would break, failing to return the VOTable status document to the higher
> level client code.
>
> Anyway, it seemed to me that the current draft supports this
> distinction, which is already used successfully in our current DAL
> services (and should not be changed without a compelling reason), hence
> is ok as written.
>
>   	- Doug
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9A 2L9

250-363-0044 (office) 250-363-0045 (fax)