Fw: SOAP/XML Protocol and filtering, etc.

Do we have a summary of the design decisions surrounding our current
approach to SOAPAction?

Cheers,

----- Original Message -----
From: "Hari Rao" <hari.rao@oracle.com>
To: <mnot@pobox.com>
Sent: Tuesday, February 18, 2003 4:55 AM
Subject: RE: SOAP/XML Protocol and filtering, etc.


>
> Mark,
>
> A few questions in connection with your original mail to
> `firewall-wizards_at_nfr.com'
>
> - Do you have an update on the design decisions for the SOAPAction
> header?
>
> - Do you happen to have pointers to filtering/access control techniques
> used for identifying HTTP headers and to act upon them?
>
> - What is your take on filtering based on content as opposed to just the
> headers? There is the inevitable cost involving CPU cycles with the
> former approach
>
> Thanks a bunch!
>
> Hari
>
>
>                          > The W3C's XML Protocol WG [1], which is
> chartered with developing
>                          > XML-based messaging based on SOAP [2], has
> been debating the merits
>                          > of the SOAPAction header in SOAP's HTTP
> binding. I've taken it upon
>                          > myself (with some misgivings ;) to solicit
> comments on the designs
>                          > being discussed.
>                          >
>                          > Briefly, SOAPAction is intended to identify a
> service being accessed,
>                          > independently from its URL. For example, if
> you're accessing a
>                          > StockQuote service, you might put a URI which
> identifies this type of
>                          > service in the SOAPAction header.
>                          >
>                          > The primary motivation of this is to allow
> firewall and filtering
>                          > proxies to identify SOAP messages in HTTP and
> act appropriately.
>                          >
>                          > Some implementations and/or applications of
> SOAP also use SOAPAction
>                          > for dispatch, but that's out of scope for
> this discussion.
>                          >
>                          > The three major designs being proposed are:
>                          > - allow any arbitrary URI to be placed in the
> SOAPAction header [3]
>                          > - force the content of the SOAPAction header
> to be the same as the
>                          > top-level XML namespace in the message body,
> thereby identifying
>                          > what kind of message it is (making this
> information available in
>                          > the header removes the requirement that the
> intermediary parse
>                          > the XML) [4]
>                          > - removing SOAPAction and requiring that only
> one service be
>                          > associated with any particular URI [5]
>                          >
>                          > I feel that if we're going to design
> something to satisfy an external
>                          > requirement ("make SOAP play nice with
> firewalls, so they don't just
>                          > block all SOAP messages"), we should consult
> with the affected
>                          > communities.
>                          >
>                          > So, I would very much appreciate:
>                          > - constructive comments as to the designs
>                          > - pointers to mailing lists, etc. of
> communities that would be
>                          > interested in these issues (firewall admins,
> etc.)
>                          > - discussion of whether any such hints will
> be helpful for the
>                          > target audience
>                          > - pointers to filtering/access control
> techniques already used,
>                          > with particular emphasis on whether or not
> any current
>                          > implementations can identify HTTP headers and
> act upon them.
>
>
>

Received on Tuesday, 18 February 2003 10:29:54 UTC