- From: Mark Nottingham <mnot@akamai.com>
- Date: Mon, 23 Apr 2001 12:55:10 -0700
- To: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Cc: soapbuilders@yahoogroups.com, xml-dist-app@w3.org
Just thinking out loud... There seem to be a number of conflicting interests re: what do to with a fault. It seems *most* tied to an application's message exchange pattern (i.e., request/response will probably send a fault back in the response, one way will probably propogate the fault to the destination if possible, etc.). I can imagine that default fault handling behaviours might be defined for each, and a module can be built that will explicitly tell processors what do do with faults in the exception cases. On Sun, Apr 22, 2001 at 07:11:57PM -0700, Henrik Frystyk Nielsen wrote: > > The basic SOAP processing model described in [1] doesn't know about > servers or clients but only "SOAP processors" which is the reason why > SOAP in general walks a fine line when talking about *generating* a > fault vs. *sending* a fault. The latter is only mentioned in the HTTP > binding and the RPC convention as these two talk about "requests" and > "responses". That is, SOAP distinguishes between generating a fault and > sending a fault message somewhere. > > Within the context of a request/response model, I think the right thing > for an HTTP client that cannot accept/obey the SOAP message semantics is > to fault the processing or to suggest that the message is saved for > later processing by a more savvy processor. The latter is similar to > what clients do when receiving a response with an unknown media type. > > It is important that a SOAP processor doesn't break the processing model > and merely ignores the SOAP rules just because it may not be in a > position where it can notify the sender about the fault. > > Henrik > > [1] http://www.w3.org/TR/SOAP/#_Toc478383491 > > Doug Davis wrote: > > > >I see 3 choices: > > 1 - ignore it > > 2 - fault back to the server > > 3 - fault back to the client > > > >While 2 is probably what "should" happen, I doubt many > >will be able to support this. 1 seems most likely, but > >scares me. 3 seems like a nice middle of the road solution. > >8-) > > > >Paul Kulchenko wrote: > > > >Since it's possible to return Header from server to client > >also, what should client do if this header has mustUnderstand > >attribute or wrong actor? -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Received on Monday, 23 April 2001 15:55:50 UTC