From: Dave Winer (dave@userland.com)
Date: Thu Aug 31 2000 - 16:11:37 PDT
Needless to say this was discussed to death in the two years we've been
working on this stuff.
My pov: XML-RPC is exactly equivalent to CGIs. If you want to know what's
going on you have to look at the body of the HTTP message.
SOAP, because it doesn't specify a transport, is different. I don't
understand all the issues, and I think this is where some of the concerns on
the xml-dist-app list have come from.
My two cents, ymmv, fyi, wadr, ianal, etc.
Dave
----- Original Message -----
From: "Fielding, Roy" <fielding@eBuilt.com>
To: "'Steve Dossick'" <sdossick@ipal.com>; "Jim Whitehead" <ejw@ics.uci.edu>
Cc: <FoRK@xent.com>
Sent: Thursday, August 31, 2000 4:05 PM
Subject: RE: [HTTPfutures] Dan Connolly on HTTP goofs and musings / Two Way
Web
> > Jim Whitehead wrote:
> > > I dunno, maybe it's just because Roy is/was my officemate, and I've
> > > mind-melded with him, but I thought this was obvious.
> > >
> > > HTTP exposes its commands in a known location in the message, and the
> > > universe of commands is predefined in a community reviewed and
approved
> > > standard. Hence, the syntax and semantics of commands are knowable by
> > > intermediaries, such as proxies and firewalls. Since the semantics
are
> > > known ahead of time, it is possible to do a thorough security
analysis,
> and
> > > then make informed decisions concerning what messages are allowed
> through
> > > firewalls.
> >
> > This is kind of a red herring, no? GET requests can have the same
> > semantic effects on the back-end database of a server as a POST or PUT
> > can, depending on the code processing them. If I choose to architect my
> > application that way, I can get around all the 'community approval' of
> > the semantics of HTTP.
>
> Doing that doesn't "get around" anything. The client is still making
> semantically-clear requests to the server, and if the server chooses
> to misinterpret those requests then it only harms the server, which is
> outside the firewall's concern.
>
> > The real issue is that the web is so fundamental to so many companies
> > doing business these days that HTTP can't really be blocked at the
> > firewall.
>
> Normal HTTP interaction is socially prevented from being blocked at
> the firewall. However, it can be selectively blocked, translated to
> harmless forms, rate-limited in the outbound direction, and inspected
> for information that does not fit the pattern of normal behavior.
> This stuff is already done by real firewalls.
>
> The reason that port-based firewalls are prevalent is because it is easier
> to filter at the TCP level and because it protects the most significant
> concern -- internal services that assume only one organization can access
> them. Web servers tend to be designed for access by clients outside the
> organizational domain, which makes the developers more paranoid about
> things like stack overflow protection. This different perspective extends
> to the administrative interfaces as well -- access to Web resources is
> granted selectively, by name, rather than assuming anything reachable
> by the server should be accessible to the client.
>
> Database services, in contrast, are expecting to be accessed by clients
> in the same organizational domain. That is why SOAP is a bad idea and
> will be blocked at the firewall. SOAP allows the naive developers at
> Microsoft to install a generic library within the OS that will "solve"
> their application problems with firewalls by allowing generic RPC
> mechanisms to be tunnelled through HTTP. What they haven't figured out
> yet is that the firewall exists to stop those generic access mechanisms,
> and it is completely brain-dead of them to assume that it will continue
> to be passed through firewalls just because the traffic is on port 80.
> Firewall software will adapt because that is the single most important
> reason-to-buy feature of a firewall, and SOAP will become just the least
> efficient way to transmit RPC within intranet-only applications.
>
> There is a lot more to HTTP interaction than standard semantics.
> The hypermedia paradigm of representing application state as pages
> containing the next set of state-transitions is much easier for
> an intermediary to analyse than typical RPC interaction, particularly
> when compared to stateful protocols. The same goes for URLs when
> compared to things like GUIDs. The result is a pattern of interaction
> that is easy to understand, and hence easy for third parties to
> layer upon, modify, optimize, etc. These things matter for the
> architectural design of Internet-based systems.
>
> ....Roy
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 16:20:10 PDT