RFC for DALI-1.0

[Markus Demleitner]

Hi DAL,

On Mon, Mar 25, 2013 at 03:52:11PM -0700, Patrick Dowler wrote:
> 
> 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

This, I think, is uncontentious, and is IMHO completely in the spirit
of HTTP.

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

I'm all for this; however, I don't think the current text makes that
clear.  Plus, I'm afraid there's no consensus about that in the WG
(see below).

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

I would maintain it's better for clients all around -- if they'd get
a 200, they can reasonably expect they can start processing data
rather than peeling off another layer of transport signalization.

Since I'm making noise anyway, let me quickly comment Doug's points:

> On 03/14/2013 09:28 AM, Douglas Tody wrote:
> >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

What's the use case for this distinction?  Why would any client care
whether a failure happened "at the HTTP level" (and frankly I'm not
quite sure what's that supposed to mean) or whether a failure
happened... well, somewhere else?

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

Partly, that's the whole point.  If I can use a library's built-in
error detection, that's great.  Even if I'm using curl to operate a
service, with proper error codes I don't have to handle the situation
where everything seems fine but the VOTable contains an error message
rather than data.

Now, if you're writing a more advanced client that actually wants to
distinguish different failure modes or display error messages or
something like that -- well, all libraries that aren't completely
broken let you access the message body even for non-200 messages.  We
shouldn't design our protocols for libraries that are broken beyond
redemption (which are these, by the way?).

And no, we should definitely not use the HTTP status code to
distinguish between "VOTable response" (=200) and "something else"
(= not 200).  There's the content-type header for that.

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

Hmha, I'd maintain that "It's an abuse of HTTP" and "It's not good to
say 'hey, everything's fine, and here is your error message'" are
fairly compelling reasons not to do put something down in what
essentially is a blueprint for future standards.

Legacy services would continue to use the existing pattern, so
nothing would break.  Future specifications would have the more
streamlined pattern.

Actually, I think there'd be one reason one might consider compelling
to *keep* the old behaviour, and I suspect it is why the
200-for-errors rule entered in the first place: CGI scripts.  Unless
you're using their non-parsed-header variety, you don't really
control what status code is being returned with them.  *If* we want
to allow DAL services as plain CGIs, we have to shut up about status
codes.

My take on the CGI issue is, though, that if you can't even write an
nph CGI, you shouldn't be in the business of writing interoperable
network services in the first place; we now have plenty of packages
you could be using to publish your data that are ready-made for you
and that (hopefully) actually implement the standards.  

Hence, I'd say with the experience of 10 years of VO behind us, we
could now correct the earlier design descision as "being more trouble
that it's been worth".

Again, this is not anything like a veto, if I had one.  If everyone
but me thinks returning 200 for error messages is fine, I'll shut up.

Cheers,

           Markus