A complete proxy server should speak all the Web protocols, the most important ones being HTTP, FTP, Gopher, WAIS and NNTP. Proxies that only handle a single Internet protocol such as HTTP are also a possibility, but a Web client would then require access to other proxy servers to handle the remaining protocols.
cern_httpd, which is one of the HTTP server programs, has a unique
architecture in that it is currently the only HTTP server that is
built on top of the WWW Common Library, which is otherwise just used
by Web clients. Unlike other HTTP servers which only understand the
HTTP protocol, cern_httpd is able to speak all of the Web protocols
just like Web clients can as all the protocols are implemented by
libwww.
cern_httpd has been able to run as a protocol gateway since version
2.00, released in March 1993, but additional features were required so
the cern_httpd could act as a full proxy. With version 2.15, the
server was enhanced to accept full URLs. The same server can now act
as a proxy server for multiple protocols since the client always
passes a full URL, thus allowing the proxy to understand which
protocol to use to interact with the destination server. The CERN
httpd can even act simultaneously as a normal HTTP server, serving
local files in addition to proxying.
The server has been greatly improved during the spring of 1994. The original implementation didn't pass the access authorization information to the remote server which is essential in accessing protected documents. The body part of the message which is present with POST and PUT methods was not forwarded prior to version 2.15, which prevented HTML forms from working with the POST method.
Caching of documents has been introduced, giving noticeable speed-ups in retrieve times. Caching is a wide subject on its own and will not be studied in great detail in this paper.
It is also possible to compile a special SOCKS version of
cern_httpd - this means that the proxy server does not
have to run on the firewall machine, but rather it speaks to the
outside world through SOCKS. Note, that this means "SOCKSifying" only
the httpd, not the client programs.
In FTP the passive mode (PASV) is supported, in case a firewall administrator wants to deny incoming connections above port 1023. However, not all the FTP servers support PASV which causes a fall-back to normal (PORT) mode. This fails if incoming connections are refused, but this is what would happen in any case, even if a separate FTP tool was used.
