- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 30 Apr 2001 19:29:50 -0700
- To: XML Distributed Applications List <xml-dist-app@w3.org>
[my mail blew up last week, so I'm posting this from home (yes, I still work at Akamai!), and as a result this won't be properly threaded] So, I never really understood the SOAPAction header, but I think I might now. SOAPAction allows the service to be identified, while the request-line URI allows the service to be located. For example, I could design a SOAP service that allows invalidations to be sent to caches. Individual deployments will be at different URLs, so that they can be located, while SOAPAction allows the message to be identified as an instance of that service, without tying it to its location. This is primarily useful for software which handles the SOAP messages but does not process the messages (such as HTTP intermediaries which need to make decisions like access control), as well as being useful as a dispatch hint for processors. Is this well-aligned with other people's conception of SOAPAction? For me, this is primarily illuminated by background from URI/URN/URL distinctions... RE: response code - the IANA registry is at http://www.isi.edu/in-notes/iana/assignments/http-status-codes P.S. - I found the comments comparing SOAP to JSP, CGI, etc. revealing. We're designing a protocol, not an application platform, although I've heard several external people express surprise about that ;) -- Mark Nottingham http://www.mnot.net/
Received on Monday, 30 April 2001 22:29:56 UTC