[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: SOAP-RPC and REST and security

• To: <zkenyon@s...>,<xml-dev@l...>
• Subject: RE: SOAP-RPC and REST and security
• From: "Dare Obasanjo" <dareo@m...>
• Date: Wed, 20 Feb 2002 15:11:46 -0800
• Thread-index: AcG6YYblamCGKJeeQPimOWKPPMEGSgAAarmg
• Thread-topic: SOAP-RPC and REST and security

Like I said, your point is lost on me. A SOAP request is typically an
HTTP POST with XML in the body of request. Many web applications use
HTTP POST as a means of submitting form data instead of putting it in
GET request URLs. However until this fairly absurd tangent on XML-DEV I
have NEVER heard anyone say that if suddenly we convert all web
forms/applications to use HTTP GET instead of HTTP POST, web
applications would suddenly be more secure. 

I expect that the people who are making the REST is more secure argument
are primarily trying to promote an agenda instead of thinking critically
about their statements which is rather unfortunate.  

-- 
THINGS TO DO IF I BECOME AN EVIL OVERLORD #119
I will not attempt to kill the hero by placing a venomous creature in
his room.
It will just wind up accidentally killing one of my clumsy henchmen
instead.


> -----Original Message-----
> From: Zach Kenyon [mailto:zkenyon@s...] 
> Sent: Wednesday, February 20, 2002 2:44 PM
> To: xml-dev@l...
> Subject: RE:  SOAP-RPC and REST and security
> 
> 
> On 20 Feb 2002, at 14:11, Dare Obasanjo wrote:
> 
> > Most people I know writing web applications are smart 
> enough to know 
> > not to write them in C or C++.
> 
> There are an awful lot of componants ((D)COM(+) as an 
> example) writted in 
> C++.  Not to mention the fact that lots of server/middleware/database
> products are written in C/++.
> 
> > Most web applications are written in Java,
> > ASP (VBScript/Jscript), and Perl. None of which I've seen 
> have a problem
> > with buffer overflows. 
> 
> Not in and of themselves.  But scripting languages do tend to 
> use things on 
> the server that do have problems with buffer overflows.  
> When's the last time 
> you saw a web application implemented wholly in VBScript 
> without the use 
> of COM/DNA/CS2K/etc?
> 
> > It's one thing to be against clients remotely executing 
> code on a server
> > and another to scapegoat SOAP in an ill-conceived attempt to garner
> > negative press towards a misunderstood technology. 
> 
> I think you've just proven one of Paul's points - REST, as 
> implemented by 
> passing URIs around is more widely understood than SOAP.  Why add 
> YALayer with all of it retooling requirements into the mix?  
> Why not build on 
> what we already have - and what's already proven to be wildly 
> successful?
> 
> SOAP is cool, don't get me wrong.  I just don't see the need 
> to add that 
> much more complexity to what boils down to essentially PUT-GET-POST-
> DELETE.
> 
> > After all, buffer overflows are possible in all web 
> applications written
> > in unsafe languages. Whether they use SOAP or not is 
> inconsequential. 
> 
> True.  Bugs increase with complexity.  Reduce the complexity.
> ----------------------------------------------------
> Sign Up for NetZero Platinum Today
> Only $9.95 per month!
> http://my.netzero.net/s/signup?r=platinum&refcd=PT97
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 

• Follow-Ups:
  • Re: SOAP-RPC and REST and security
    • From: Paul Prescod <paul@p...>
  • Re: RE: SOAP-RPC and REST and security
    • From: Mike Champion <mc@x...>
  • agendas
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: SOAP-RPC and REST and security
• Next by Date: RE: SOAP-RPC and REST and security
• Previous by thread: RE: SOAP-RPC and REST and security
• Next by thread: agendas
• Index(es):
  • Date
  • Thread