Re: Clarification

From: sponge (
Date: 12/11/03

Date: 10 Dec 2003 18:50:08 -0800

On Wed, 10 Dec 2003 11:52:09 -0500, "Jim Hubbard"
<valid@email.address> wrote:

>To clarify my previous question.....
>I am writing a webserver for a class project and I need to write one
>reasonably emulates a standard webserver, and does so in the most
>and most efficient way possible.
>Option 1 : I can write a webserver that handles HTTP requests on a
>port (80) in rapid succession. However, this severely limits the
>scalability and maximum simultaneous clients of the webserver.
>Option 2 : I can also write one that takes the incoming requests on
port 80
>and assigns each one to a daemon that actually accepts the request
>communicates with the client. This solution would mean that the
>communicating with the client is not necc. on port 80 of the
webserver but
>still the same IP. This maximizes scalability and allows for the
>number of simultaneous clients on the webserver.
>If firewalls are typically set up to allow outgoing HTTP requests
only to
>port 80 of a webserver, option 2 may not be the best method. If
>typically allow HTTP request to webservers that expose ports other
than 80
>(i.e. if outgoing HTTP requests are not restricted to port 80 on
>webservers), option 2 will be the fastest and most scalable solution.
>Any pointers or help that you can offer would be greatly appreciated.
>Thanks for your help.

>From the client end, here's the deal. IF the client is not firewalled,
an HTTP request can be made to any port on the webserver. IF the
client IS firewalled with a software firewall, it may depend. Most
allow connection on any port, but many folks (myself included)
restrict browsers to only 80 (and SSL). Furthermore, many companies
will disallow HTTP except on 80 or may restrict what ports are used,
so, either way, using oddball ports can be problematic. Above all,
many, many services -- both business, personal, ISP's, etc. - use
proxies, which often require HTTP on port 80. I think that trend is
only going to increase as admins realize that closing every port
possible is a (very) necessary evil and also that proxies are a useful
and often extremely effective security tool.
Even though I don't fully understand precisely how you expect Option 2
to work, the bottom line is, I don't see any way Option 2 is workable
if you're dependant on the ports issued by the client, unless your
product were relegated to a limitied or special use, such as an
internal company webserver. And even there it could be problematic.
OTOH, the idea is not a complete dead-end. Have you explored the idea
of using a daemon running on port 80 to serve as a pre-processor to
divvy up and forward traffic to separate servers for processing? You
can certainly FORWARD traffic received by your preprocessor to any
port you like, since any data received is past both the client's and
the server-side firewall. That might be a happy medium.

Sponge's Secure Solutions
My new email: yosponge2 att yahoo dott com