- From: Scott Lawrence <slawrence@virata.com>
- Date: Tue, 08 May 2001 11:11:11 -0400
- To: Dick Brooks <dick@8760.COM>
- CC: moore@cs.utk.edu, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Mark Nottingham <mnot@akamai.com>, ietf@ietf.org, xml-dist-app@w3.org
It seems to me that the argument for using the SOAPAction header is based on two conflicting points: - that the action needs to be identified outside the HTTP body so that it can be used by a message broker to dispatch the body without understanding it. and - that the message broker cannot use the URI because it is not a part of the HTTP server Either the message broker is part of the server, can use a header value (including the URI) and the body is opaque, or it isn't and should use the body but not the headers. It seems to me that together, these argue for an additional layer of encapsulation - send a message broker body (whatever that is) in the HTTP message (with the URI of the message broker and a content type that identifies it as a message broker message), and then within that body encapsulate a SOAP message, with whatever metadata the message broker needs to dispatch it. If an additional encapsulation sounds harder to deal with in a firewall, then you begin to understand what firewalls are for. The objective, IMHO, should not be to design protocols so that we can poke them through firewalls - that is a bad way to use firewalls. We should instead design things so that it is easy for services to be offered outside firewalls when that is appropriate (yes, this is hard, but it is the real problem and the hacks to avoid solving it only make it worse). We should not permit upper-layer protocols to poke information arbitrarily far down into the stack in order to label the payload as 'ok to pass through security' unless we have also defined ways for that label to be appropriately secured. If we can have SOAP reaching past the 'message broker' to HTTP with its label, why not have it reach past HTTP to add a TCP option? When put that way it seems silly - the HTTP option really isn't any better. As for the specific question that began this thread (whether the SOAPAction header is useful or not), I can offer an implementation perspective. We've implemented the 0.9 version of SOAP as a part of our UPnP implementation. SOAP/0.9 is carried in HTTP and does include the SOAPAction header. It also includes the same information (the action identifier) in the XML body of the message. We found the potential conflict between these to be a major pain to deal with, especially since the namespace was represented differently in the header and body (which meant that the comparison had to be namespace-aware, it couldn't just be the equivalent of strcmp). -- Scott Lawrence Architect slawrence@virata.com Virata Embedded Web Technology http://www.emweb.com/
Received on Tuesday, 8 May 2001 11:11:29 UTC