From: Fielding, Roy (fielding@eBuilt.com)
Date: Thu Aug 31 2000 - 16:05:17 PDT
> 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:09:46 PDT