W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Summarizing the last 192 discussion

From: Grahame Grieve <grahame@kestral.com.au>
Date: Mon, 01 Apr 2002 22:30:14 +1000
Message-Id: <5.1.0.14.2.20020401222436.00af9090@www.kestral.com.au>
To: xml-dist-app@w3.org
At 07:43 PM 31/03/2002 -0500, you wrote:
>Looks good Noah.  One minor comment;
>
> > 2a. Regardless of the envelope, the HTTP code should take precedence.  A
> > SOAP fault received with a 200 cannot be a fault...though I'm not quite
> > sure what it is then! (Mark Baker)
>
>It's still a fault, it's just not processed as one.  Like when HTML
>is sent as text/plain; it's still HTML, just not processed as HTML.


sorry - I don't understand. Since HTTP says it's not a fault, well
the application will just pretend that it wasn't. how does that make
sense?

This whole thing seems a bit strange to me. We insist that a SOAP
fault be represented as a HTTP 500 (or 5xx?) since somehow that
is deemed to be "better". So are we also going to insist that
all the other HTTP response codes be used appropriately.
For instance, I might insist that if a method response simply
consists of a confirmation of message receipt, with no other
information, then the HTTP status code should be 202, whereas
normally, it should be 200.

Also, how could one implement SOAP-on-HTTP but by using a
generic HTTP library? how can one not model it as "tunneling"
when actually doing the implementation?

Grahame
Received on Monday, 1 April 2002 07:38:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT