Network Computingwww.networkcomputing.com

		our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

When the first firewalls went up to protect a handful of companies from the ravages of the Internet, only a few services had to be supported: FTP, SMTP and telnet. Then, along came HTTP and it changed the whole nature of firewalls. In fact, it took some time for firewall vendors to figure out the basics of handling HTTP authentication. Over the past six years, however, firewalls have become increasingly capable of handling HTTP traffic, both outbound and inbound. And the number of firewalls has increased as well. Today, thousands of firewalls are deployed to limit a company's exposure to the Internet. These firewalls are fairly set in their behavior and have become a barrier to new Internet applications.

These new applications want to traverse the firewalls. And the application users typically aren't interested in the corporate Internet security policy; they just want their applications to work. So, Internet-application vendors are using HTTP as a shortcut through firewalls. You, the corporate networkologist, must choose your side--with your security team or with your end users.

There's nothing new about picking an underlying protocol, or substrate, for an application based on market pressures. The Internet community has a long tradition of protocol reuse, dating back to the use of NVT (network virtual terminal) as a substrate for telnet, FTP and SMTP.

Technical rationalizations are always available to confuse the issue. Be prepared to face significant pressure to accept any of them just to move forward. First, there's the familiarity and mind-share argument. It's easier to familiarize programmers with HTTP than train them on a newly created protocol. Then, there's the compatibility concern. If HTTP is used, the new application is "automagically" compatible with widely deployed browsers--and you probably don't need to be reminded that you don't want to upgrade in the middle of the year 2000 conversion. Of course, time-to-market is always a concern, and the ability to reuse existing servers and client libraries can be a very compelling point. Indeed, HTTP server support is needed on the application server anyway, so why not just use it and gain the benefit of CGI scripts for prototyping?

The self-justification is almost comical. Only occasionally do I hear that HTTP's ability to traverse firewalls is what really counts.

Technically, HTTP is a session-layer protocol in the classical OSI model. So is there anything wrong with picking the most-available session layer in the IETF for a new application? It seems that groups working on new protocols like the IPP (Internet Printing Protocol) are determined to use HTTP. But this raises a number of issues for both the corporate manager and the Internet community. Should the application use a different port than the HTTP default of 80? Port 80 works through the firewalls, but results in the standard HTTP server needing to take on this new application function (you can only have one application server on a port on a system). Should the application use traditional HTTP methods or should it define new methods? Standard Web client/server competition will be driving enhancements to those methods that could work against a new application's use of them. Finally, should the application use "http:" URLs or define its own prefix? The answers to these questions will have a long-term impact on your networking and security plans.