- From: Roy T. Fielding <fielding@ebuilt.com>
- Date: Fri, 14 Dec 2001 19:43:45 -0800
- To: Keith Moore <moore@cs.utk.edu>
- Cc: Mark Baker <distobj@acm.org>, Brian E Carpenter <brian@hursley.ibm.com>, janssen@parc.xerox.com, discuss@apps.ietf.org
> given the complexity and weaknesses of HTTP and the wide variety of > behavior in the deployed HTTP infrastructure, it's often more work > to figure out and specify how to use HTTP to do something, than it > is to design your own protocol. No. It is hard to use HTTP to do something for which it was specifically designed not to do well. All protocols have trade-offs in order to match the efficiencies of the requirements at the time they were designed, and much of HTTP's requirements centered around deployability in a heterogeneous, multi-organizational environment. To consider a protocol's design in isolation of its context is a poor way to create systems. Almost all of HTTP's complexity is due to two things: MIME syntax and the optional features of content/encoding negotiation. The only thing hard about building an HTTP service is dealing with the raw TCP socket handling bugs in operating systems and browsers. > HTTP often works okay on a small scale. But I have yet to see someone > suggest using HTTP for a widely-used protocol who truly understood > the implications of that design choice. HTTP is still better than any other published protocol for what it is intended to do. Mark's point, which I think he is belaboring, is that the same application can be designed in many ways, some of which will work well with the Web paradigm and some of which will work against it. That doesn't mean HTTP is the best way of implementing all applications. It simply means that there are good uses of HTTP and bad uses of HTTP. I'd rather burn time on replacing HTTP with something more efficient, but for the same architecture, than waste it trying to make HTTP efficient for all architectures. In any case, HTTPR is a silly idea because it attempts to use HTTP as a transport protocol, which is a total waste of bits. Firewalls exist for a reason, and that reason won't change just because more companies try to wedge their protocols through TCP 80. The firewalls will just adapt to block them by content, and the resulting systems will fail in ways that will be a customer-service nightmare. DOA, just like DCOM over HTTP, but it will keep happening over and over again as long as people fail to understand the reasons HTTP is not a transport protocol (beyond the simple notion of efficiency). ....Roy
Received on Friday, 14 December 2001 23:00:14 UTC