Re: [HTTPfutures] Dan Connolly on HTTP goofs and musings / Two Way Web

Date view Thread view Subject view Author view

From: Roy T. Fielding (fielding@kiwi.ICS.UCI.EDU)
Date: Sat Aug 19 2000 - 17:49:35 PDT

>The main reason it is the only practical protocol is that it can break
>through firewalls. Breaking through firewalls is probably a bad thing, but
>that doesn't matter - developers make their own decisions. If they can't
>get through the firewall any other way then they will overload HTTP.
>Because HTTP is bad at RPCs what we are getting is slow and unreliable apps.

No. The apps were slow and unreliable when they were using DCOM, just
as they were when using IIOP, and were when they were using ONC RPC.
The apps are going to be slow and unreliable as long as you continue
building architectures that are ignorant of the forces that influence
Internet-scale systems. Using HTTP as a transport just makes them slower.

>Back to Adam's original question: can the One Way Web evolve into the Two
>Way Web? I'd say that, because HTTP is bad at RPCs, the One Way Web has to
>evolve into the Two Way Internet. Let HTTP keep doing what it is designed
>for, which is browser/server interactions. To evolve we need either an HTTP
>2.0 that properly supports RPCs or we need new protocols that can also break
>through firewalls.

Then what you should be doing is figuring out why HTTP makes it through
firewalls, even though firewalls predate HTTP. The theory that these
protocols will be able to get through firewalls just because they are
running on top of HTTP is just plain wrong.

>> Design the protocol based
>> on how you want the components to be constrained, and they will have
>> no choice but obey the architecture. Complaining about the same
>> constraints when trying to use the protocol within a completely different
>> architecture is inane
>I can't go there with you. Developers serve users; protocol designers serve

That's absurd. The firewalls exist to protect users. Developers advocating
generic RPC tunneling through firewalls are serving their own interests, not
that of the users.

Architects use protocols to enable a defined set of communication. The
degree to which that communication is visible to intermediaries determines
whether or not it can be safely passed through a firewall. Now what is
it about HTTP that makes it different from RPC, and thus safe for transfer
through firewalls?


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Aug 19 2000 - 17:53:21 PDT