- From: Rich Salz <rsalz@zolera.com>
- Date: Thu, 19 Jul 2001 08:14:57 -0400
- To: Mark Baker <distobj@acm.org>
- CC: xml-dist-app@w3.org
> SOAP processors, even those using HTTP, are not HTTP user agents so are > not bound by this requirement. No but intermediate hop-by-hop HTTP agents have no way of knowing. > So what's wrong with using the application semantics of the protocol That is exactly what we should do. We just disagree that 500 is a valid status code to contain application data. If a SOAP target wants a digitally signed message, and doesn't get it, should it return 401, or should it leave that to the HTTP layer in case the POST requires a basic auth? If doing SOAP over email, a fault can only be returned by sending a reply message, not by responding with a 451 status and using continuation lines. Right? Once you start to "tightly integrate" SOAP messaging semantics with the underlying transport, all sorts of nasty corner cases come up, like the two I just mentioned. That's why it's much simpler and much more clear to think of it as tunneling. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com
Received on Thursday, 19 July 2001 08:13:51 UTC