Re: 2xx/202 and "a priori"

OK, I understand.  I still claim that our binding is intended to talk only 
to our binding.  If I do a SOAP request post, and accidently hit a disk 
save service, the fact that it responds with a 202 is 100% reliable 
indication that I was not talking to the intended node.  Using our binding 
to talk to such a node is an error!  I believe it should be modeled as a 
soap error.

You might thing of it this way:  let's say I'm defining a voice phone 
control interface.  Clearly, if I get "no answer", that's a connection 
error.  Given that I'm looking for voice connections, I claim that a fax 
tone is an error too.  Now, the phone system (compare with HTTP) doesn't 
consider it an error (compare with 202 or 204).  Other applications of the 
phone system (fax machines -- compare with other SOAP bindings or other 
uses of HTTP) don't consider it an error.  For an application specifically 
written to control voice connections, it's an error.

You can never insist that what's an error at one level won't be success at 
another, or visa versa.  You may always ahve context that tells you what's 
expected or unexpected.  As a roundabout example, let's say I have a 
system what has as its sole purpose to make sure that certain web 
resources are unavailable (granted, this is an unusual appliction.)  For 
such an application, 200 is an error, and 404 is success.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Baker <distobj@acm.org>
05/16/2002 12:05 PM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xml-dist-app@w3.org
        Subject:        Re: 2xx/202 and "a priori"


On Thu, May 16, 2002 at 10:53:51AM -0400, noah_mendelsohn@us.ibm.com 
wrote:
> I'm not an HTTP expert.  You're saying that a typical HTTP server, when 
> confronted with a POST that it does not understand, responds with a 
> "success" code (I.e. 204)?  Who woulda thought?

I'm not claiming it's typical, just that it is a perfectly valid thing
to do as an HTTP application.  I provided an example that demonstrated
this earlier;

http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0205

The issue is that "understand" is defined solely by the service.  For
a save-to-disk service, it might choose to "understand" everything.
This is a result of POST's definition in RFC 2616, which says;

   "The actual function performed by the POST method is determined by
    the server [...]"

>  BTW: to which message of 
> Henrik's are you referring?

Primarily the last paragraph of this one, though it doesn't explicitly
reference the form example (which was from a w3c-xml-protocol-wg post);

http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0042

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Thursday, 16 May 2002 12:29:03 UTC