Re: FW: TBTF: Proposal for issue 196

 David, in tuneling binding sending everything via 200 is the
logical approach. AFAICS the current situation results from an
attempt to accommodate both approaches in one binding.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 3 Apr 2002, David Crowley wrote:

 > 
 > 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 Thursday, 4 April 2002 09:15:38 UTC