Re: SOAP/XML Protocol and filtering, etc.

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(_at_)virata(_dot_)com
Virata       Embedded Web Technology    http://www.emweb.com/