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

Re: FW: TBTF: Proposal for issue 196

From: David Crowley <dcrowley@scitegic.com>
Date: Wed, 03 Apr 2002 10:19:36 -0800
Message-Id: <5.1.0.14.0.20020403101316.03873150@mail.internal.scitegic.com>
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: <xml-dist-app@w3.org>

For a non-chameleon binding, I would propose that if a SOAP request is 
received (or at least the requesting mime type is "application/soap+xml") 
and a SOAP envelope is returned then the response code should always be 
200.  Keep the 400 and 500 error codes for when things really go south, 
when the servers handling thread dies (500), when the request comes in as 
"POST /soap HTTP/2.0" (505); for when an error occurs at the HTTP level.

(Waiting for Mark's hair to stand up on the back of his neck.)

David


At 09:20 PM 4/2/2002, Henrik Frystyk Nielsen wrote:

>Reposted... Henrik
>
>Problem
>-------
>
>This mail is primarily intended for TBTF folks but others are free to
>read along. Jean-Jacques brought up the issue that table titled
>"Responding State SOAP Faults" [3] in the Mar 23 snapshot [2] contains a
>series of ?? where HTTP status codes should be listed:
>
>       Non-fault Response Message          200 OK
>       env:VersionMismatch                 ??
>       env:MustUnderstand                  ??
>       env:DataEncodingUnknown             ??
>       env:Sender                          ??
>       env:Receiver                        ??
>       env:rpc                             ??
>       Other faults                        ??
>
>TBTF started discussing this on today's TBTF call but didn't finish so I
>took an AI to take it to the list. The proposal below does not
>necessarily represent consensus within the TBTF or anywhere else for
>that matter.
>
>Discussion
>----------
>
>* As we now have sub-fault codes, rpc fault goes away entirely and so do
>"other faults".
>
>* I would also think that DataEncodingUnknown should be a sub-fault of
>"Sender" [see e] rather than a top-level fault.
>
>* Personally, I don't think the first "non-fault" entry should be listed
>in this table as it is not a SOAP fault and it is described elsewhere in
>the binding.
>
>Proposal
>--------
>
>As a result of the discussion, I think the table will look like this:
>
>       env:VersionMismatch                 500 [see a]
>       env:MustUnderstand                  500 [see b]
>       env:Sender                          400 [see c]
>       env:Receiver                        500 [see d]
>
>[a] Similar to HTTP/1.1's 505 "HTTP Version Not Supported"
>[b] Similar to HTTP/1.1's 501 "Not Implemented"
>[c] Similar to HTTP/1.1's 400 "Bad Request"
>[d] Similar to HTTP/1.1's 500 "Internal Server Error"
>[e] Because the sender sends something that the receiver can't accept
>
>Comments?
>
>Henrik Frystyk Nielsen
>mailto:henrikn@microsoft.com
>
>[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x196
>[2] http://www.w3.org/2000/xp/Group/2/03/23/soap12-part2-1.46.html
>[3]
>http://www.w3.org/2000/xp/Group/2/03/23/soap12-part2-1.46.html#http-resp
>bindrespond
Received on Wednesday, 3 April 2002 13:20:10 GMT

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