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.
[EMAIL PROTECTED] on 05/07/2001 09:47:16 AM
To: Mark Nottingham <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED](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 [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
att1.eml
