SOAPAction thoughts from elsewhere

To get a better idea of the requirments and design of SOAPAction,
I've posted messages to the main IETF list, and later two
firewall-specific lists. The threads are included in the URLs below.

I'd note that Kieth Moore is the author of the 'Using HTTP as a
substrate...' draft, and Darren Reed is the author of IPFilter, and
an acknowledged security/firewall expert.

The subject is "SOAP/XML Protocol and filtering, etc". There are some
good thoughts throughout.

  http://www.ietf.org/mail-archive/ietf/Current/threads.html
  http://www.nfr.com/pipermail/firewall-wizards/2001-May/subject.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200105/threads.html

I've also attached the messages I've gotten, as some haven't shown up
in the archives yet.

If anyone or the group would like me to pass a message or question
on, please just ask.

Cheers,


-- 
Mark Nottingham
http://www.mnot.net/

Forwarded message 1

  • From: Jeff.Hodges@kingsmountain.com <Jeff.Hodges@kingsmountain.com>
  • Date: Sun, 06 May 2001 00:07:23 -0700
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: ietf@ietf.org
  • Message-Id: <200105060707.AAA21364@breakaway.Stanford.EDU> 
Two firewall community lists you might try are..

  firewall-wizards@nfr.com  <http://www.nfr.com/firewall-wizards/>

  firewalls@Lists.GNAC.NET  <http://lists.gnac.net/firewalls/>


There was a short thread on the latter list (around the first of this year) 
along similar lines to your query. The thread was entitled..

  "new" protocols vs. firewalls & firewall adminis{trators|tration} ?

  http://lists.gnac.net/firewalls/mhonarc/firewalls.200012/msg00786.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200012/msg00789.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200012/msg00792.html


  http://lists.gnac.net/firewalls/mhonarc/firewalls.200101/msg00071.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200101/msg00080.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200101/msg00072.html
  http://lists.gnac.net/firewalls/mhonarc/firewalls.200101/msg00075.html


JeffH

Forwarded message 2

  • From: Keith Moore <moore@cs.utk.edu>
  • Date: Sun, 06 May 2001 15:12:08 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: ietf@ietf.org
  • Message-Id: <200105061912.PAA18003@astro.cs.utk.edu> 
The last thing that HTTP needs is yet another tag with which to 
de-multiplex incoming traffic.  Adding application-specific 
request or response headers just increases the problems that 
already exist due to a lack of clean layering in HTTP.  So I'd 
strongly recommend against defining any new SOAP-specific headers.

As for demultiplexing, my recommendation would be to do whatever 
SOAP-specific demultiplexing either entirely within the URL of the 
request, or entirely within the HTTP payload.   (and SOAP should
choose one of these, not make it a per-service option). If the 
latter is chosen, the separation between the SOAP payload and the 
tag used for demultiplexing could be done either using XML framing 
or with MIME multipart/something.  This ensures the maximum 
compatibility with existing servers, server-side APIs, proxies, 
and client APIs.  It also keeps HTTP servers from having to know
specifically whether a particular URI corresponds with a SOAP 
request (in which case it might have to look at the SOAPAction header 
in order to know how to handle it) or not (in which case the SOAPAction
header should be ignored).

The name of the SOAP service should *not* be inferred from the XML 
namespace used to describe the request.  This would make it impossible 
to have multiple services that accept identically formatted requests.

Keith

Forwarded message 3

  • From: Keith Moore <moore@cs.utk.edu>
  • Date: Sun, 06 May 2001 17:46:16 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: Keith Moore <moore@cs.utk.edu>, ietf@ietf.org
  • Message-Id: <200105062146.RAA18816@astro.cs.utk.edu> 
> On Sun, May 06, 2001 at 03:12:08PM -0400, Keith Moore wrote:
> > and client APIs.  It also keeps HTTP servers from having to know
> > specifically whether a particular URI corresponds with a SOAP
> > request (in which case it might have to look at the SOAPAction header
> > in order to know how to handle it) or not (in which case the SOAPAction
> > header should be ignored).
> 
> Yep; seems to me that Content-Type ss more appropriate for dispatch,
> if doing it in a header is desireable.

ugh.  only if you must.  the URL is *far* better for this purpose.
 
> > The name of the SOAP service should *not* be inferred from the XML
> > namespace used to describe the request.  This would make it impossible
> > to have multiple services that accept identically formatted requests.
> 
> The idea is that the identity (i.e., "this is a stockquote service")
> is implied by the namespace, and therefore is useful for firewall
> admins, etc., so they can work at the granularity of a service type.
> The location of the service is still carried in the HTTP
> request-line. SOAPAction isn't intended to uniquely name services.

I can see why you might want firewalls to be able to filter certain
kinds of data - having everything tagged in XML might allow firewalls
to prevent inadvertent leakage of data of types known to be 'sensitive'
via any of several protocols. But I don't think you really want to 
conflate the name of the data structure with the name of the service, 
and probably not even with the 'type' of the service.  The type of 
the service and the type of data presented to the service should be 
kept separately.

Keith

p.s. One thing that really concerns me about the SOAP approach is what I 
call firewall escalation - the chief justification for using HTTP as a 
substrate for SOAP is to allow it to operate through existing firewalls, 
but one of the consequences of SOAP is likely to be that firewalls become 
more complex (and more error-prone) due to a need to dig deeper into the 
HTTP payload.  This degrade service for all uses of HTTP.  So I think 
SOAP should be designed, to the extent possible, to avoid encouraging 
such escalation.  

And if it ends up requiring changes to HTTP after all, and/or changes
to existing firewalls, then it should be declared to be a different 
protocol, with a different default port, with a different URI prefix.  
That way, the firewall measures that get put in place for SOAP don't 
end up affecting use of ordinary HTTP.

Forwarded message 4

  • From: Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu>
  • Date: Mon, 07 May 2001 00:01:07 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: ietf@ietf.org
  • Message-Id: <200105070401.f47418L20704@foo-bar-baz.cc.vt.edu> 
On Sun, 06 May 2001 12:59:36 PDT, Mark Nottingham said:
> The idea is that the identity (i.e., "this is a stockquote service")
> is implied by the namespace, and therefore is useful for firewall
> admins, etc., so they can work at the granularity of a service type.
> The location of the service is still carried in the HTTP
> request-line. SOAPAction isn't intended to uniquely name services.

OK.. I've read section 6 of http://www.w3.org/TR/SOAP several times,
and I'm frankly dissapointed.

Unless you find a way to codify that the site has to tell the
truth in the SOAPAction, it's a non-starter.  Consider that
the user behind a firewall could, in conjunction with a site
that supported it, just tack onto the end of the URL a

&callit=whateverSoap

and the web site could just label it with SOAPAction=whateverSoap
will get through the firewall.

So what is this actually fixing?  The guy *inside* the firewall
presumably knows what will be allowed to pass, and can tell the
guy outside what to call it.  This sounds like a scene from a
James Bond movie - if he knows that the roadblock up ahead is
looking for a Jaguar with Swiss plates, he hits a button and
he's now driving a Jaguar with French plates.

This leaves us with 2 choices:

1) Require the SOAPAction to match the XML.  Since the firewall
has to poke around the XML then, it renders SOAPAction redundant
and useless.  It's also a protocol layering violation egregeous
enough to cause retching.

2) Accept that it's yet another broken protocol that confuses
authentication with authorization (in the worst way - it trusts
the value it's given).  I *have* to point out that 4 of the 8
authors work for a company which has historically had problems
in understanding that an attacker might <*gasp*> put incorrect
data into a header field....

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Forwarded message 5

  • From: Brian E Carpenter <brian@hursley.ibm.com>
  • Date: Mon, 07 May 2001 06:32:19 -0500
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: ietf@ietf.org
  • Message-Id: <3AF687C3.8D5E1414@hursley.ibm.com> 
Mark Nottingham wrote:
> 
> Jeff and Kieth,
> 
> Thanks for the comments; any others would be much appreciated. I'd
> note that there is also discussion of an e-mail (SMTP, if you like)
> binding of SOAP as well, in addition to HTTP. Same issues (though it
> doesn't have a SOAPAction-type mechanism yet AFAIK.)

Not mention a BEEP binding, or so I have heard. 
 
     Brian

Forwarded message 6

  • From: Melinda Shore <mshore@cisco.com>
  • Date: Mon, 7 May 2001 08:25:05 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: "Keith Moore" <moore@cs.utk.edu>, "Mark Nottingham" <mnot@akamai.com>
  • Cc: <ietf@ietf.org>
  • Message-ID: <01d301c0d6f0$c118d8a0$d45904d1@cisco.com> 
> p.s. One thing that really concerns me about the SOAP approach is what I 
> call firewall escalation - the chief justification for using HTTP as a 
> substrate for SOAP is to allow it to operate through existing firewalls, 
> but one of the consequences of SOAP is likely to be that firewalls become 
> more complex (and more error-prone) due to a need to dig deeper into the 
> HTTP payload.  This degrade service for all uses of HTTP.  

Note, as well, that any assumption that you can get
through a firewall by inspecting content implies that 
the firewall can read that content - in a very real
sense the use of stateful inspection firewalling works 
against securing applications.

Melinda

Forwarded message 7

  • From: Jeffery.Gieser@minnesotamutual.com <Jeffery.Gieser@minnesotamutual.com>
  • Date: Mon, 7 May 2001 08:47:16 -0500
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: firewalls@Lists.GNAC.NET
  • Message-ID: <OFE77593F0.3337921D-ON86256A45.004A790C@minnesotamutual.com> 
Mark,

     Maybe I am missing something here but I thought that the whole point
of developing SOAP was so that application developers could do stuff
without having to bother the pesky firewall administrator.  I block SOAP
and I probably will continue to do so regardless of the identification
placed in the SOAP header.  HTTP is bad enough without making the transport
protocol for everything else under the sun.  The SOAPAction header sounds
nice but I think that most firewall administers will just block SOAP until
they are ordered not to.

Regards,
Jeffery Gieser

-
[To unsubscribe, send mail to majordomo@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]

Forwarded message 8

  • From: Dawes, Rogan (ZA - Johannesburg) <rdawes@deloitte.co.za>
  • Date: Mon, 7 May 2001 16:16:01 +0200
  • Subject: RE: SOAP/XML Protocol and filtering, etc.
  • To: "'Mark Nottingham'" <mnot@akamai.com>, firewall-wizards@nfr.com
  • Message-ID: <98A3855A9087D411952F00508B61BD4001EE2DF0@ZAJNBNT006> 
Hi Mark,

The key thing to me is, what happens if the SOAPAction and the URI disagree?

It would be simple to craft a message that would pass the firewall, based on
the SOAPAction header, but turn out to call a completely different function
based on the content of the XML.

This suggests a flaw where one party (the firewall) permits an action, based
on some information (the SOAPAction header), while the next party (the
web-server/application server) takes action based on other information (the
actual content of the XML)

This seems to be asking for trouble.

I would be happier to have a proxy that parsed the XML and took action based
on the same information that the application server would be using.

Rogan

-----Original Message-----
From: Mark Nottingham [mailto:mnot@akamai.com]
Sent: 07 May 2001 07:46
To: firewall-wizards@nfr.com
Subject: [fw-wiz] SOAP/XML Protocol and filtering, etc.



[This was originally posted on the main IETF list, and it was
suggested that this was a good place to go for input...]

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.

Kind regards,

[1] http://www.w3.org/2000/xp/Group/
[2] http://www.w3.org/TR/SOAP
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
_______________________________________________
firewall-wizards mailing list
firewall-wizards@nfr.com
http://www.nfr.com/mailman/listinfo/firewall-wizards

Forwarded message 9

  • From: Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu>
  • Date: Mon, 07 May 2001 10:25:19 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: ietf@ietf.org
  • Message-Id: <200105071425.f47EPJL23544@foo-bar-baz.cc.vt.edu> 
On Sun, 06 May 2001 22:34:17 PDT, Mark Nottingham said:
> My original question was whether this behaviour was useful; although

I don't think it is..

> firewalls can (and some undoubtably will) break open the XML to try
> and figure out what's inside, SOAPAction gives those who merely wish
> to have some reasonable control over what SOAP messages pass into and
> out of their network.

No, it doesn't provide reasonable control.  Since the whole *point* of
a firewall is to stop malicious packets, and since a packet can simply
label itself as "non-malicious", it leaks too much.

We *already* have too many networks out there run by people who think
that because they've installed a firewall, they're secure.  I'm going
to have to protest tooth-and-nail any proposal that will give even a
HINT to "the unwashed masses" that they can say "We installed a firewall
that implements SOAP, we dont have to worry about bad SOAP packets".

I have *NO* objections to implementing SOAPAction so that software can
use it as a "hint" for possible fast-pathing or special handling of some
sort (for instance, to flag it as SOAP-compliant so a SOAP handler can
be loaded, or to flag it as "priority" for expedited handling, or for
purposes similar to 'content-type:'.  If somebody comes across a good
way to use SOAPAction: headers to make the Akamai node across the hall
from me do even more cool caching things, I'll encourage that ;)

I only object to the implication that it's reasonable to use it for
yes/no decisions in a firewall or other security context.
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Forwarded message 10

  • From: Bill_Royds@pch.gc.ca <Bill_Royds@pch.gc.ca>
  • Date: Mon, 7 May 2001 10:27:34 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Jeffery.Gieser@minnesotamutual.com
  • Cc: Mark Nottingham <mnot@akamai.com>, firewalls@Lists.GNAC.NET
  • Message-ID: <85256A45.004F6EA1.00@pch.gc.ca> 
SOAP is an attempt to formulate a better structure for client-server exchanges
than the present grapbag of CGI scripting.
If SOAP is such a problem, why not also block anything with a CGI request in it
or POST altogether?
What is impoortant is to have a syntax for client-server exchanges that can be
parsed unequivocally so that  intermediate filters such as firewalls or web
proxies do not interpretet the meaning differently from each other, the server
or the client.
If the SOAPaction verb in HTTP allows us to be clearer, it can only help
firewalls.
  Unfortunately, SOAP is coming along a little late in the game. Most systems
will always need to support CGI and other scripting so SOAP adds to the
complexity rather than replaces it by a better paradigm.





Jeffery.Gieser@minnesotamutual.com on 05/07/2001 09:47:16 AM
                                                              
                                                              
                                                              
 To:      Mark Nottingham <mnot@akamai.com>                   
                                                              
 cc:      firewalls@Lists.GNAC.NET(bcc: Bill                  
          Royds/HullOttawa/PCH/CA)                            
                                                              
                                                              
                                                              
 Subject: Re: SOAP/XML Protocol and filtering, etc.           
                                                              






Mark,

     Maybe I am missing something here but I thought that the whole point
of developing SOAP was so that application developers could do stuff
without having to bother the pesky firewall administrator.  I block SOAP
and I probably will continue to do so regardless of the identification
placed in the SOAP header.  HTTP is bad enough without making the transport
protocol for everything else under the sun.  The SOAPAction header sounds
nice but I think that most firewall administers will just block SOAP until
they are ordered not to.

Regards,
Jeffery Gieser

-
[To unsubscribe, send mail to majordomo@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]

Attachments for message 10

  • application/octet-stream attachment: att1.eml

Forwarded message 11

  • From: Bill_Royds@pch.gc.ca <Bill_Royds@pch.gc.ca>
  • Date: Mon, 7 May 2001 10:42:18 -0400
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: Mark Nottingham <mnot@akamai.com>
  • Cc: firewall-wizards@nfr.com
  • Message-ID: <85256A45.0050C75B.00@pch.gc.ca> 
There was an earlier conversation about this that looked at risks with SOAP
through HTTP. THe feeling was that we feared that SOAP would allow anything to
be tunneled over HTTP, necessitating restricting SOAP altogether.
The main problem is ensuring that the syntax of the proposal is strict enough
that the limits on semantics are captured.
Since a firewall is looking at a stream for syntax violations for the most part
and not actually executing the command, it has difficulty with commands that are
open ended in syntax, as witness the recent problems with Unicode on IIS. Having
a match between HTTP headers and bodies helps to bound the possible states to
check.
Thus option 1 is not firewall friendly becaue it allows actions in SOAPaction
header to be combined with essentially aribtrary data. Option 2 is safest while
3 is similar to what happens now.
 Something else that would be useful for firewalls is a way to maintain state
over a SOAP session. An arbitrary but inique identifier in HTTP header (part of
SOAPaction header perhaps)created by first SOAPaction request and echoed on
further transactions linked to that request would allow the application firewall
to maintain the stream and preven cross URI transfer of data if not allowed by
security policy.
  Most present application gateway firewalls like Raptor, Sidewinder, Gauntley
et al. do match the HTTP actions and headers with argument checking.
So, for example, a GET command must have a valid URI following it follwed by a
HTTP version command or nothing separated by blanks. Extra stuff on the line
will cause it to be rejected.
  Most of the time, Application gateways look at the HTTP part (headers) for
control and the body part for syntax only (terminated properly with CR/LF blank
line between headers and body etc.). They don't normally ahve the ability to
actually parse the HTML or XML.
So it is important to have the SOAPaction header match the SOAP xml code in the
body. That at least provides some place for authentication. If the body allowed
arbitrary SOAP commands with the header indicating anything, security would
require rejecting any SOAP.




Mark Nottingham <mnot@akamai.com> on 05/07/2001 01:45:56 AM
                                                              
                                                              
                                                              
 To:      firewall-wizards@nfr.com                            
                                                              
 cc:      (bcc: Bill Royds/HullOttawa/PCH/CA)                 
                                                              
                                                              
                                                              
 Subject: [fw-wiz] SOAP/XML Protocol and filtering, etc.      
                                                              






[This was originally posted on the main IETF list, and it was
suggested that this was a good place to go for input...]

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.

Kind regards,

[1] http://www.w3.org/2000/xp/Group/
[2] http://www.w3.org/TR/SOAP
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html


--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
_______________________________________________

Forwarded message 12

  • From: Darren Reed <darrenr@reed.wattle.id.au>
  • Date: Tue, 8 May 2001 00:48:01 +1000 (EST)
  • Subject: Re: SOAP/XML Protocol and filtering, etc.
  • To: mnot@akamai.com (Mark Nottingham)
  • Cc: firewall-wizards@nfr.com
  • Message-Id: <200105071448.AAA29320@avalon.reed.wattle.id.au> 
Hi Mark,
        Let me add some thoughts....I've been playing with XML of late
and have found it an interesting game, along with DTD's and such.

> 
> The three major designs being proposed are:
>   - allow any arbitrary URI to be placed in the SOAPAction header [3]

Has any consideration been given to a maximum length ?

>   - 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]

I don't agree with that argument.  What it does allow is for the firewall
to enforce a proper relationship between SOAPAction and the XML document.
Who's to say that both endpoints involved in the SOAP communication are
bug free with respect to enforcing this rule?

So where does that put you?

You can't trust the SOAPAction to be correct (if the message is transitting
a firewall) so you may as well ignore it.  Thus you're going to need to parse
the SOAP document anyway to verify that SOAPAction matches the first element.
I.e. what's the point of having the SOAPAction there in the first place?
Also, why repeat the same information twice?

In some sense it's like saying the MIME type is an authorative comment on
what the content of an email body actually is.  This is far from the truth,
even though 9 times out of 10 it will be a match because that's where the
real benefit comes from for users, today.

Hmmm, the more I think about what's going on there, the more I agree with
your comments in [5].

What I'm curious about is how and why the URI in SOAPAction might be
different to that in the HTTP method.  i.e why shouldn't they both start
at / ?  What if a firewall sees a SOAPAction and HTTP method that are
vastly different after the leading / ?  Since XML/SOAP is self describing
using text and the content type is already xml, what real meaning or role
can SOAPAction apart from being a dangerous shortcut?

Something I notice that is missing from the SOAP document and that's a DTD.
That'd be of real value to a firewall since it could use that to enforce
all SOAP documents were well formed before allowing them through.  It might
take CPU and a few milliseconds, but it does give you added value in your
SOAP filtering.

Darren

Received on Monday, 7 May 2001 12:58:06 UTC