> > 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..
SOCKS allows you to define which networks (specified by numeric network
addresses and mask combinations) should be accessed directly, and which
networks should be reached via particular proxy servers (you can have
more than one proxy, if you wish, each serving particular network
areas).
Why bother with this fine control?
Well: SOCKS comes at this specifically from the side of providing
services through _Firewalls_.
Think of a typical, real Firewall configuration, where a bastion host on
a restricted `DMZ' segment between the internal networks and the
Internet aims to provide proxy service for internal clients. It can
instigate connections outwards on behalf of client systems, but it
cannot instigate connection inwards, into the internal net.
This is what SOCKS was designed for. It already provides all the
service transport and access control stuff. It needs the fine control
over which connections go via a proxy on the bastion system for this
reason: it's not simply that it's less _efficient_ to send connections
to internal hosts via a proxy, unnecessarily. Rather, if a connection
does get passed unnecessarily to the proxy it will _not be possible_ for
it to connect inwards to the local host at all. The connection will
fail.
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.
SOCKS has been getting established in use for providing WWW access through
firewalls. As you'll know, X Mosaic now ships with hooks to link in the
SOCKS library; Aleks Totic has mentioned on the `mmosaic-fire' mailing
list that Mac Mosaic is to do the same; and SOCKSized versions of Lynx,
and even of the CERN httpd have been described on the `socks' lists. All
of these involve hooks patched into the build of versions of the libwww
code. Is there any interest at CERN in hooking SOCKS into the `master'
WWW library, to centralise all this effort and do away with the
duplication?
I.
-- Ian Dunkin <[email protected]>--