[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
Amy Lewis wrote: > >...[re WSDL] > So do parameterized URLs. Parameterized URLs are something that travels across the wire at runtime. They are analogous to the SOAP *message* which is generally also very hard to read. >... > > >Then why not use a TCP protocol? It would actually *reduce* the > >compexity of the spec, clear up the SOAPAction question. Clear up the > >"Web architecture" question. Improve performance. > > Actually, no. SOAP addresses data format and message exchange > patterns, it's silent on connection setup/teardown, state versus > stateless, and many more things that an application protocol would have > to specify first. It is still my contention that the TCP binding of SOAP would not be any more complicated than the HTTP binding. You make it sound like defining connection setup/teardown is hard over TCP. It isn't. Look at Jabber for example. > ... BEEP and Jabber both provide XML over TCP > application protocols (or application protocol toolkits, in the case of > BEEP), and spend most of their time there, very little (compared to > SOAP) on message format and exchange patterns. That is not true at all. http://docs.jabber.org/general/html/protocol.html The Jabber specification talks in great detail about message format and exchange patterns. And it says about connection roughly: "open two connections, one each way." > >> *shrug* With a big honking SoapAction on them, in case anyone bothers > >> to look. > > > >SOAPAction is deprecated. > > SOAPAction *will be* deprecated. 1.2 isn't released yet. So? It will the first standardized version of SOAP. > >> ... The two are not the same. If there is a network admin in > >> the world who allows free deployment of servlets, components, or > >> whatever into the corporate firewall, he ought to be fired for > >> incompetence *before* the first SOAP server gets dropped in (on top of > >> the NCSA finger CGI, perhaps?). > > > >How can the network admin *even know* that such a server is running. It > >just looks like a standard HTTP POST, right? If their policy allows POST > >then it will be very hard for them to disallow SOAP. > > How can a network admin *not* know? Because often the POST is going *out*. Here's what MSN Messenger's documentation says today: ============= What do I do if I have a firewall? No matter what kind of firewall you have, you will need to configure it to allow the computers within it to open outgoing TCP sockets to allow your network users to use MSN Messenger Service. Computers on the internal local area network will need access to the Domain Name System (DNS) servers to resolve the names of external hosts such as microsoft.hotmail.com. As network administrator, you need to do the following: ? To enable the use of MSN Messenger Service: Open outgoing TCP Port 1863, and configure it so that sockets on this port are open for extended periods of time. ? To enable the use of AOL Instant Messenger (AIM) integration with MSN Messenger Service (Windows only): Open outgoing TCP Port 5190, and configure it so that sockets on this port are open for extended periods of time. ============ So MSN uses a new port so that by default it is blocked by strict firewall policies. That's good, because a security hole in MSN could expose the entire internal network, even if the connections are made from the inside out. A few years from now MSN will probably run on SOAP because it is the up and coming generalized protocol substrate. If the SOAP world keeps going the way it is going, Messenger will run on port 80 and everything will look like an HTTP POST. What will the documentation look like then? ============ You need to buy a new firewall with built-in XML parsing capabilities. Look for the following namespace within the SOAP:Body element. ============ >... > >"Well-known" port numbers exist for a reason. Can you offer a good > >reason why SOAP should use port 80? Other than firewalls? > > So use 25. SOAP has to use some existing port, because it isn't an > application protocol. That's simply untrue. The SOAP RPC binding to HTTP could specify a port number. > ... It's a formatting standard for existing > application protocols. Yes, that's one way to look at it. In fact Mark Baker has an essay to that effect. Unfortunately SOAP is an extremely poor "formatting standard" for the HTTP protocol. Also since when is a "formatting standard" a protocol at all. The question of what exactly SOAP is is unanswerable because it is different things to different people. It's so general and vague as to be a rorschach for the XML crowd. > >Based on...parsing the XML text? Anyhow, why is the onus on the sysadmin > >to exclude. That's not the way the Internet has historically worked. > > Quite true. It's the way it works now, though, and has been since lots > and lots of toys with random unused but vulnerable services were > attached. There's no going back, alas; we're no longer as trusting as > we were when the Morris worm hit. So you're saying it is perfectly appropriate for every new protocol from now until infinity to use port 80. And when sysadmins start filtering on XML content then it will be appropriate to define a new standard that embeds S-expressions in the XML so that the new protocol is "firewall friendly." > >But more important, SOAP is a superset of RPC so it has no reliable > >internal structure, addressing model or even message pattern. It's > >transparent to humans but opaque to computers! > > Horsefeathers. > > The purpose of the silly thing is to provide standardization of content > in application protocols; I'm sorry. I don't see the requirment to add a SOAP header and SOAP body to an XML message as "standardization". As a firewall admin that's the *only thing* I can be confident that an arbitrary SOAP message will have. That's it. The rest is optional. (unless I've missed something recently) >... that's just about all that the specs address > with the wonderfully misleading HTTP binding and RPC patterns. With friends like these, SOAP hardly needs enemies. Paul Prescod
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|