I would appreciate a better description. How does it leave the HTTP intermediary out of sync with the SOAP/HTTP processors? Why does a fault have to be any more than just a message in this case? Ray Whitmer rayw@netscape.com Mark Baker wrote: >>Ray Whitmer writes: >> >>>>Great, I can live with that. >>>> >>Terrific, thanks. Now let's see whether anyone else can :-). >> > >Sorry, but I can't. 8-( > >The more I think about it, the more this is an R803[1] issue. It is >critical, for the chameleon use, that a HTTP intermediary participating >in a chain of SOAP/HTTP intermediaries, have a consistent view of what >the SOAP/HTTP processors understand to be success or failure. Because >in the chameleon view, this is all happening, SOAP and HTTP, at the >same layer in the stack. > >If I understood your suggestion correctly, you're saying that a >receiving SOAP processor should treat a fault received over 200, even >after acknowledging that it's broken, as a fault. Doing this would >leave the HTTP intermediary out of sync with the SOAP/HTTP >processors, as it has no knowledge of this SOAP-specific heuristic. >This would violate R803. > > [1] http://www.w3.org/TR/xmlp-reqs/#z803 > >MB >Received on Friday, 29 March 2002 12:31:10 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:41:51 GMT