Re: XML Protocol: Proposals to address SOAPAction header

Good point Chris.

It is important that the SOAPAction URI be preserved between gateways. 
One wouldn't think of transferring SOAP messages without a notion of
"content type" though, right?  So perhaps my suggestion[1] of moving
SOAPAction to be a parameter (presumably mandatory) on a
application/soap+xml media type would help.

It's still "just" syntax, but the need to preserve that information
would be more explicit when more tightly associated with an existing
concept that already requires preservation.

 [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0189.html

MB

christopher ferris wrote:
> 
> I echo Larry's concerns regarding this revised proposal.
> It does little to improve the situation and still does not
> address how SOAPAction is communicated across different
> transport protocols. If a SOAP message starts out being
> communicated over the Frobnaz transport protocol, which does
> NOT have a SOAPAction header (or even a place to put one)
> and the message is being sent via a Frobnaz->HTTP gateway,
> where does the gateway get the appropriate SOAPAction
> to put in the HTTP headers when it forwards the message
> to the ultimate destination?
> 
> Cheers,
> 
> Chris
> 
> 
> Larry Masinter wrote:
> >
> > > - I would be interested in hearing what you think about that
> > >
> > >   http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0053.html
> > >
> >
> > I don't see how this has fixed the problem, though:
> >
> > # The presence and content of the SOAPAction header field MAY be used by
> > # servers such as firewalls to appropriately filter SOAP HTTP request
> > # messages and it may be used by servers to facilitate dispatching of SOAP
> > # messages to internal message handlers etc. It SHOULD NOT be used as an
> > # insecure form of access authorization.
> >
> > * Exactly how is it that a firewall might use a SOAPAction header
> >  to "appropriately" filter SOAP HTTP request messages?
> >  As far as I can tell, there's not enough information to decide
> >  which requests with which SOAP action headers the firewall should
> >  accept, and which it should reject, or even what a firewall that
> >  rejects such a message should signal its rejection. Treat it as
> >  an attack? The main purpose of firewall filtering is to prevent
> >  unwanted or malicious traffic, but there's no reason to believe that
> >  malicious SOAP messages would contain a correct SOAPAction header.
> >  So I don't think the first application "appropriate filter SOAP
> >  HTTP request methods" has been reasonably justified, at least in
> >  this fragment of text.
> >
> > * The second application for SOAPAction headers given is that
> >   it "may be used by servers to facilitate dispatching", but
> >   the only way that a server might use a SOAPAction header would
> >   be if there were some specification of which kind of SOAPAction
> >   headers should be dispatched and which should not, and where
> >   they should be dispatched. Is the SOAPAction header like another
> >   kind of RequestURI?
> >
> > So I think this attempted clarification does nothing
> > to respond to the criticism that the value of the SOAPAction
> > header is not specified well enough for it to be used for
> > its stated purposes.
> >
> > Larry
> > --
> > http://larry.masinter.net

Received on Monday, 11 June 2001 13:35:57 UTC