Re: Submission and protocol 'errors' [was RE: Cancel a submission in progress]

On 4/11/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> I don't think we're going to resolve this quickly, but I don't mind because
> this is a big issue.

I tend to agree with you on both accounts :)

> > I do not agree with that. XForms should not take a clear
> > error statement from the underlying layer and turn it into a
> > "no error".
> > That is very wrong in my eyes. Fine if it was
> > "soap://foo.bar.com/request", and SOAP defined clearly that
> > the information should be used. But converting a clear http
> > error into a "non-error"? I'm not in favor of that.
> >
> > I do agree that 1) the information returned by the server on
> > an error could be useful and 2) proper soap handling needs
> > this. But imho, it still needs to be an error message, and it
> > needs to take a different and distinct path than that of a
> > success response.
>
> I understand the concern, but the problem with the way that HTTP is being
> used nowadays for transferring data is that an error is not necessarily an
> error! (In other words, there is no such thing as the "clear error
> statement" that you would like.)

Well, the http protocol does say that 4xx are errors, which is what I
meant by "clear errors". But yes, people are (imho, unfortunately)
twisting that.

> As an example, say I have a RESTful interface to my contact database and I
> ask for person 300. The XML is returned fine with an HTTP 200, I interact
> with the data, and all is well with the world. I then ask for person 250,
> who doesn't exist, and the server returns an HTTP 404 with some XML message
> that says the customer no longer exists, and if I think they *should* then I
> can contact the sysadmin on extension 333.

(Well, it is a design question. Amazon and Flickr f.x. use HTTP 200,
do they not?)

> In this scenario what exactly is the error? There is no failure of
> communication (for example, the network), since we asked for data, and got
> stuff back. Sure there is a 404 'error' but that is not a catastrophic
> failure--it's just that we designed our system (in good RESTful fashion) to
> make use of the HTTP error codes to pass back extra information.

Yes, it was a couple of days since I visited RFC2616 though, but for
some reason I just visited it again :) And, a bit to my surprise, for
4xx errors it actually states:
"Except when responding to a HEAD request, the server SHOULD include
an entity containing an explanation of the error situation, and
whether it is a temporary or permanent condition."
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4]
The "SHOULD include an entity" had found its way out of my memory. So
I am warming a bit more up to the idea :).

> So I'm not saying that XForms should turn this into 'no error'--I'm saying
> that the system designer already has! As far as this system is concerned
> there is no error in the sense of *failure*.

The designer is a failure then ;-)

> The big bit that is missing in XForms is the "examine the response" part I
> just described, since at the moment we do not have access to the headers and
> status codes from the underlying protocol.

Well, I think we agree on that we need to expose more of the
submission process to the form author. I have not thought too much
about it though, so I do not currently have any pros or cons for your
proposals or a solution either. I guess, what I fear is, that the form
author ends up replacing his instance data with an error document.
This is why I want a "distinct path" (I'm searching for a better
word...).

--
... Allan

Received on Tuesday, 11 April 2006 14:47:50 UTC