Re: Proxy Servers (and SOCKS)
altis@ibeam.jf.intel.com (Kevin Altis)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 25 Feb 1994 21:31:02 --100
Message-id: <m0pa93m-00041aC@ibeam.intel.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: altis@ibeam.jf.intel.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: altis@ibeam.jf.intel.com (Kevin Altis)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Proxy Servers (and SOCKS)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3199
At 12:48 PM 2/25/94 +0000, Ian Dunkin wrote:
>On Wed, 16 Feb 1994 11:37:28 Tim Berners-Lee <timbl@ptpc00.cern.ch> wrote:
>
>> > Each client application will have to decide when to proxy and when not to.
>
> [...]
>
>> Yes. I think that a simple and common case will be that
>> anything within a certain single domain will be local access.
>
>The SOCKS proxy mechanism has already addressed this one, but its
>solution uses a configuration _file_, which allows more elbow room for
>fine adjustment than environment variables -- where I can see that your
>space can quickly get cluttered..
The current proxy reliance does have some setup weak points, but I would
prefer that the setup not become as complex as SOCKS. The two issues to
address are:
1. Being able to specify one or more proxy servers to use. While the
environment variable is simple, it doesn't allow for the case of a proxy
server going down or for any kind of load balancing across proxy servers. A
configuration file or environment variable listing multiple servers
available for use would be more appropriate. A configuration list might
associate particular proxy servers to be used with particular domains. This
would allow a single configuration list to be used across an entire
organization.
2. Clients should not have to proxy all requests for a particular protocol,
though some sites may choose to do this. The simple case as Tim mentioned
is for "local" requests (within your domain) not to be proxied. This can be
done via a simple string compare by the WWW client. This case can actually
be handled by an environment variable setting. The more complex case may
require a SOCKS style configuration list. There is also the possibility of
wanting to go through a separate proxy for "local" requests to take
advantage of caching by your local proxy. This would imply a "protocol -
domain - proxy server" kind of mapping.
Most sites that require the use of a proxy would not need anything more
than the ability to specify a proxy for a particular protocol, plus a
domain or domains to not proxy. I need specific examples if this doesn't
work for your site so we can understand your needs.
>This is why I think that SOCKS and the clever Montulli/Luotonen/Altis
>scheme are complementary, and not competetive: the M/L/A scheme seems to
>come more from the direction of providing _connectivity_ for particular
>WWW services, not exclusively for use with Firewalls.
Actually, the proxy scheme is intended to be a complete replacement for
SOCKS in the case of Web clients (reliance on HTTP), while SOCKS can
continue to work for telnet and special ftp clients. There are numerous
reasons for the SOCKS replacement, but I don't want to drag all of the
reasons out on this list.
There has been a lot of confusion about the proxy, which is mostly my fault
for printing the t-shirts :-) before doing the documentation (old
programmer habit). I knew the idea was sound, but I didn't think this
initial beta would be so widely used so quickly. Much credit goes to Ari,
Lou, etc. that it all works so well. I will be working on preliminary
documentation of the proxy this weekend and will announce the URL location
next week.
ka