CL *H
`__
`__
`EB
`ELSEVIER
`
`Abstract
`
`COMPUTER
`NETWORKS
`and
`ISDN SYSTEMS
`
`Computer Networks and ISDN Systems 27 (1994) 147-154
`
`World-Wide Web proxies
`
`Ari Luotonen a, Kevin Altis b
`a CERN, Geneva, Switzerland
`’ Intel, Hillsboro, Oregon, USA
`
`to the Web for people on closed subnets who can only
`A WWW proxy server, proxy for short, provides
`access
`access the Internet
`through a firewall machine. The hypertext server developed at CERN, cern _ httpd, is capable of
`running as a proxy, providing seamless extemal access to HTTP, Gopher, WAIS and FTP.
`to support al1 the
`ccm_httpd has had gateway features for a long time, but only this spring they were extended
`methods in the HTTP protocol used by WWW clients. Clients do not lose any functionality by going through a proxy,
`except special processing
`they may have done for non-native Web protocols such as Gopher and FTP.
`the first
`A brand new feature
`is caching performed by the proxy, resulting
`in shorter
`response
`times after
`document fetch. This makes proxies useful even to the people who do have full Internet
`access and do not really
`need the proxy just to get out of their local subnet.
`This paper gives an overview of proxies and reports
`
`their current status.
`
`1. Introduction
`
`The primary use of proxies is to allow access to
`the Web from within a firewall (Fig. 1). A proxy is
`a special HTTP [l] server that typically runs on a
`firewall machine. The proxy waits for a request
`from inside the firewall, forwards
`the request
`to
`the remote server outside
`the firewall, reads the
`response and then sends it back to the client.
`In the usual case, the same proxy is used by al1
`the clients within a given subnet. This makes it
`possible for the proxy to do efficient caching of
`documents that are requested by a number of
`clients.
`also makes
`The ability to cache documents
`proxies attractive
`to those not inside a firewall.
`
`Setting up a proxy server is easy, and the most
`popular Web client programs already have proxy
`support built in. So, it is simple to configure an
`entire work group to use a caching proxy server.
`This cuts down on nehvork
`traffic costs since
`many of the documents are retrieved from a local
`cache once the initial request has been made.
`Current proxy methodology
`is based on the
`earlier gateway code written by Tim Berners-Lee
`as part of 1 i b w w w, the WWW Common Library
`[8]. Kevin Altis, Ari Luotonen and Lou Montulli
`have been
`the principle designers behind
`the
`proxy standard.
`Lou Montulli, author of Lynx [lol, made the
`first 1 i b w w w changes to support proxying in col-
`laboration with Kevin Altis. Ari Luotonen main-
`
`Elsevier Science B.V.
`SSDI 0169-7552(94)00064-6
`
`Juniper Ex. 1053-p. 1
`Juniper v Implicit
`
`

`

`148
`
`A. Luotonen, K A1ti.s / Computer Networks and ISDN Systems 27 (1994) 147-154
`
`the
`tains the CERN h t t pd [9]. Ari has made
`server side of the proxy standard a reality and
`integrated caching into the proxy server.
`
`1.1. Why an application-leve1 proxy?
`
`An application-leve1 proxy makes a firewall
`safely permeable
`for users
`in an organization,
`without creating a potential security hole through
`which “bad guys” can get into the organization’s
`net.
`to
`For Web clients, the modifications needed
`support application-leve1 proxying are minor (as
`an example, it took only five minutes to add proxy
`support for the Emacs Web browser [13]).
`There is no need to compile special versions of
`Web clients with firewall libraries,
`the standard
`out-of-the box client can be configured
`to be a
`proxy client. In other words, proxying is a stan-
`dard method for getting through firewalls, rather
`than having each client get customized
`to support
`a special
`firewall product or method. This
`is
`especially important
`for commercial Web clients,
`where the source code is not available for modifi-
`cation.
`Users do not have to have separate, specially
`modified FTP, Gopher and WAIS clients to get
`through a firewall - a single Web client with a
`proxy server handles al1 of these cases. The proxy
`also standardizes
`the appearance
`of FTP and
`
`than each
`
`listings across clients rather
`Gopher
`client having its own special handling.
`A proxy allows client writers
`to forget about
`the tens of thousands of lines of networking code
`necessary
`to support every protocol and concen-
`trate on more
`important
`client
`issues -
`it is
`possible
`to have “lightweight” clients
`that only
`understand HTTP (no native FTP [2], Gopher [3],
`etc., protocol
`support)
`- other protocols
`are
`transparently
`handled by the proxy. By using
`HTTP between
`the client and proxy, no protocol
`functionality
`is lost, since FTP, Gopher, and other
`Web protocols map wel1 into HTTP methods.
`Clients without DNS (Domain Name Service)
`can stil1 use the Web. The proxy IP address is the
`only information
`they need. Organizations using
`private network address spaces such as the class
`A net 10. * . * . * can stil1 use the Internet as long
`as the proxy is visible to both the private intemal
`net and the Internet, most likely via two separate
`network interfaces.
`Proxying allows for high leve1 logging of client
`transactions,
`including client IP address, date and
`time, URL 171, byte count, and success code. Any
`regular fields and meta-information
`fields in an
`HTTP transaction are candidates for logging. This
`is not possible with logging at the IP or TCP
`level.
`to do filtering of client
`is also possible
`It
`transactions at the application protocol
`level. The
`
`Fig. 1. Overall setup of a proxy. Proxy server is running either on a firewall host or other internal host which has full internet
`access, or on a machine inside the firewall making connections
`to the outside world through SOCKS or other firewall software.
`
`Juniper Ex. 1053-p. 2
`Juniper v Implicit
`
`

`

`A. Luotonen, K. Altis / Computer Networks and ISDN Systems 27 (1994) 147-154.
`
`149
`
`GET /wth/doc.html
`. .
`
`HTTP/1 .O
`
`Ctient
`
`-
`HTTP
`
`some. host
`-
`
`HTTP
`sewer
`
`I
`
`HTfP/l .o 200 Document
`. . .
`
`fdkwm
`
`/
`w&)
`
`lLl
`
`Remote HIlP
`senw’s Nesvstem
`Fig. 2. A normal HTTP transaction. Client makes a request to
`the HTTP server and specifies the requested resource relative
`to that server (no protocol or hostname specifier in the URL).
`
`proxy can control access to services for individual
`methods, host and domain, etc.
`Application-leve1 proxy facilitates caching at
`the proxy. Caching is more effective on the proxy
`server than on each client. This saves disk space
`since only a single copy is cached, and also allows
`for more efficient caching of documents
`that are
`often referenced by multiple clients as the cache
`manager can predict which documents are worth
`caching for a long time and which are not. A
`caching server would be able to use “look ahead”
`and other predictive algorithms more effectively
`because it has many clients and therefore a larger
`sample size to base its statistics on.
`Caching also makes it possible
`to browse the
`Web when some WWW server somewhere, or
`even the extemal network,
`is down, as long as
`one can connect
`to the cache server. This adds a
`degree of quality of service
`to remote network
`resources such as busy FTP sites and transient
`Gopher servers which are often unavailable
`re-
`
`locally. Also, one
`motely, but may be cached
`might construct a cache that can be used to give a
`demo somewhere with a slow or non-existent
`Internet connection. Or one can just load a mass
`of documents
`to the cache, unplug the machine,
`take it to the cafeteria and read the documents
`there.
`In general, Web clients’ authors have no rea-
`son to use firewall versions of their code. In the
`case of the application-leve1 proxy, they have an
`incentive, since the proxy provides caching. De-
`velopers should always use their own products,
`which they often do not with firewall solutions
`such as SOCKS. In addition,
`the proxy is simpler
`to configure
`than SOCKS, and it works across al1
`platforms, not just Unix.
`
`2. Technical details
`
`is made by a
`request
`When a normal HTTP
`client, the H’ITP server gets only the path and
`keyword portion of the requested URL (Fig. 2);
`other
`parts,
`namely
`the protocol
`specifier
`and the hostname are obviously clear to
`“http:”
`the remote HTTP server - it knows that it is an
`HTTP server, and it knows the host machine that
`it is running on. The requested path specifies the
`document or a CG1 [6] script on the local filesys-
`tem of the server, or some other resource avail-
`able from that server.
`to a proxy
`When a client sends a request
`server the situation is slightly different. The client
`always uses HTTP for transactions with the proxy
`server, even when accessing a resource served by
`
`wwworoxv.mv.domafn
`-
`.
`some.host
`GET hlQx//sorne.host/palha(h/doc.html HllP/l.O
`GET /paltVdoc.html HllP/l .O
`ti
`
`-
`Cliint
`
`HllP/l .O 200 Document MOWS
`. . .
`http://some.host/path/doc.html
`http~roxy=http://www_proxy.my.domain/
`
`Fig. 3. A proxied HTTP transaction. Client makes a request to the proxy server using HTTP, but specifying the full URL, the proxy
`server connects
`to the remote server and requests
`the resource relative to that server (no protocol or hostname specifier in the
`URL).
`
`Juniper Ex. 1053-p. 3
`Juniper v Implicit
`
`

`

`150
`
`A. Luotonen, K Altis /Computer Networks and ISDN Systems 27 (1994) 147-154
`
`like Go-
`
`a remote server using another protocol,
`pher or FTP.
`instead of specifying only the path-
`However,
`name and possibly search keywords to the proxy
`server, the full URL is specified (Figs. 3 and 4).
`This way the proxy server has al1 the information
`necessary
`to make the actual request
`to the re-
`mote server specified
`in the request URL, using
`the protocol specified
`in the URL.
`From this point on the proxy server acts like a
`client to retrieve
`the document;
`it calls the same
`protocol module of 1 i b ww w that the client would
`cal1 to perfonn
`the retrieval. However,
`the “pre-
`sentation” on the proxy actually means the cre-
`ation of an HTI’P reply containing
`the requested
`document
`to the client. For example, a Gopher
`or FTP directory
`listing is returned as an HTML
`document.
`
`2.1. Client side issues
`
`Most WWW clients are built on top of 1 i b-
`w w w, the WWW Comrnon Library, which handles
`the different
`communication
`protocols used
`in
`the Web, namely HTTP, FTP, Gopher, News [51
`and WAIS [4].
`is handled automati-
`The entire proxy support
`cally for clients using the 1 i b w w w. Environment
`variables are used to control the library. There
`is
`an individual environment variable
`for each ac-
`cessprotocol;e.g.,
`http_proxy,
`ftp_proxy,
`and wais
`vari-
`gopher_proxy
`proxy.These
`ables are set to the URL Ginting
`to the proxy
`
`to serve requests of that
`
`server that is supposed
`protocol, e.g.
`ftp_proxy=http://www_proxy.domain:
`9lllexport
`ftp_proxy
`Usually the proxy server
`is the same for al1 the
`protocols, but does not have to be.
`for a given
`When
`the environment
`variable
`protocol
`is set, the 1 i bwww code causes a con-
`nection
`to always be made
`to the proxy rather
`than directly
`to the remote server. Some clients
`also provide additional means of configuring
`the
`client to use a proxy server (e.g. Mosaic for X 1111
`can use X resources and Mosaic for Windows [12]
`uses settings in its initialization
`file).
`The latest (as of April 1994) 1 i bw w w (version
`2.15) also supports an exception
`list so clients do
`not always have to go through
`the proxy. This is
`useful
`for avoiding
`the proxy for local servers
`where the clients can make a direct connection.
`Another differente
`in the protocol between
`the client and the proxy is that
`the requested
`URL has to be a full URL when it is requested
`from the proxy server. These are the only differ-
`ences between
`a normal
`and proxied HTI’P
`transaction. The simplicity of proxy support
`in a
`Web client means that even clients not based on
`1 i b w w w can easily support the proxy.
`for
`only
`Proxy
`support
`is
`implemented
`HTI’P/l.O on the server side so clients use that
`protocol. This is not a problem because 1 i b w w w
`does this automatically,
`and most clients (if not
`already
`been
`upgraded
`to use
`al0
`have
`HlTP/l.O.
`
`www_proxy.my.domain
`
`.O
`
`HllP/l
`-
`
`GET
`
`flp://Some.hoSt/path/doc.hlml
`
`CtlGnt
`
`HTTP
`
`PfQW
`sefvef
`*
`
`*
`
`FPresponse
`
`-
`
`.O 200 Docment
`
`fOtlOWS
`
`Hll~/.l
`. . .
`#p://some.hast/path/doc.html
`rtp_proxv=http://www_proxy.my.domain/
`
`some.host
`
`setver
`
`is
`to the proxy server, using H’lTP, even though the actual resource
`Fig. 4. A proxied FTP transaction. Client makes a request
`served by an FTP server. The proxy server sees from the full URL that an FTP connection should be made, and retrieves the file
`from the remote FTP server. Result is sent back to the client using H’lTP.
`
`Juniper Ex. 1053-p. 4
`Juniper v Implicit
`
`

`

`A. Luotonen, K Altis/Computer Networks and ISDN Systems 27 (1994) 147-154.
`
`151
`
`2.2. Server sia!e issues
`
`The proxy server has to be able to act as both
`a server and a client. It is a server when accepting
`HTTP requests from clients connecting
`to it, but
`it acts like a client to the remote servers that it
`connects to in order to actually retrieve
`the docu-
`ments for its own clients. The header fields passed
`to the proxy from
`the client are used without
`modification when the proxy connects
`to the re-
`mote server so that the client does not lose any
`functionality when going through a proxy.
`A complete proxy server should speak al1 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 h t t pd, 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
`mP
`servers which only understand
`the HTTP
`protocol, CERN h t t pd is able to speak al1 of the
`Web protocols just like Web clients can as al1 the
`protocols are implemented by 1 i b w w w.
`CERN h t t pd has been able to run as a proto-
`col gateway since version 2.00, released
`in March
`1993, but additional features were required so the
`CERN h t t pd could act as full proxy. With ver-
`sion 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 al-
`ways passes a full URL, thus allowing the proxy
`to understand which protocol
`to use to interact
`with the destination
`server. The CERN h t t pd
`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
`did not pass the access authorization
`information
`to the remote server which is essential in access-
`ing 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.
`introduced,
`Caching of documents has been
`giving noticeable
`speed-ups
`in retrieve
`times.
`Caching is a wide subject on its own and wil1 not
`be studied in great detail in this paper.
`It is also possible to compile a special SOCKS
`version of CERN h t t pd - this means that the
`proxy server does not have to run on the fire-
`wal1 machine, but rather
`it speaks to the outside
`world
`through SOCKS. Note,
`that
`this means
`“SOCKSifying” only the h t t pd, 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 al1 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 FTF’ tool was used.
`
`GEl fut-URf HllP/l .O
`
`www--roxy.my.domain
`
`Hm/1 .o 200 Poeument
`. . .
`
`rollows
`
`6 ach
`
`Fig. 5. A caching proxy.
`use.
`
`The requested document is retrieved from the remote server and stored locally on the ww
`
`server for later
`
`Juniper Ex. 1053-p. 5
`Juniper v Implicit
`
`

`

`152
`
`2.3. Caching
`
`The basic idea in caching is simple: store the
`retrieved document
`into a local file for further
`use so it won? be necessary
`to connect
`to the
`remote server
`the next time a document
`is re-
`quested (Figs. 5 and 6).
`that need
`However,
`there are many problems
`to be coped with once caching is introduced. How
`long is it possible
`to keep a document
`in the
`cache and stil1 be sure that it is up-to-date? How
`to decide which documents
`are worth caching
`and for how long?
`in the
`foreseen
`Document
`expiry has been
`HTTP protocol which contains an object header
`specifying the expiry date of an object. However,
`currently
`there are very few servers that actually
`give the expiry information, and until servers start
`sending it more commonly we wil1 have to rely on
`other, more heuristic approaches,
`like only mak-
`ing a rough estimate of the time to live for an
`object.
`since many of the docu-
`importantly,
`More
`ments in the Web are “living” documents, speci-
`fying an expiry date for them is generally a diffi-
`cult
`task. A given document may remain un-
`changed for a relatively long time, then suddenly
`change. This change may have been unforeseen
`by the document
`author and so would not be
`accurately reflected
`in the expiry information.
`
`2.4. Protocol additions
`
`that the retrieved docu-
`it is essential
`When
`ment is up-to-date,
`it is necessary
`to contact
`the
`
`A. Luotonen, K Altis / Computer Nehvorh and ISDN Systems 27 (1994) 147-154
`
`remote server for each GET request. The HTTP
`protocol already contains the HEAD method for
`retrieving a documents’ header
`information, but
`not the document
`itself. This is useful for check-
`ing if the document has been modified since the
`last access.
`the document has
`in cases where
`However,
`changed,
`it would be very inefficient
`to make a
`second connection
`to the remote server to do the
`actual GET
`request
`to retrieve
`the document.
`The overhead of making a connection
`is often
`considerable.
`to
`The HTTP protocol was therefore extended
`contain
`an
`request
`If-Modified-
`Since
`header, making
`it possible
`to do a conditional
`GET request. The GET request
`is otherwise
`the
`same except
`that
`this header contains
`the date
`and time that the object currently
`in the client
`(proxy cache) was last modified.
`If the document has not been modified since
`the date and time specified
`it wil1 not be sent
`back, instead only the relevant object meta-infor-
`mation headers, such as a new expiry date wil1 be
`retumed, along with a special result code. If the
`document has been modified
`it wil1 be sent back
`as if the request was just a normal GET request.
`The conditional GET makes several types of
`utilities more efficient. It can be used by mirror-
`ing software that has to refresh a large number of
`files on a regular basis. The caching proxy server
`could refresh its cache regularly during periods of
`client inactivity, not just at times when a docu-
`ment is explicitly requested.
`It is worth noting
`that the conditional GET
`header
`is backward compatible. HTTP
`is defined
`
`www_proxy.my.domain
`GET W-URL HTlP/l .O
`Client -
`
`Roxy
`SeNer
`
`HTTP
`
`HllP/l,O 200 Doclmlenl fonows
`. . .
`
`somehost
`
`Fig. 6. Cache hit on the proxy. If an up-to-date version of the requested document
`connection
`to the remote server is necessary.
`
`is found in the cache of the proxy server no
`
`Juniper Ex. 1053-p. 6
`Juniper v Implicit
`
`

`

`A. Luotonen, K Altis /Computer Networks and ISDN Systems 27 (1994) 147-154
`
`153
`
`so that unknown header fields are ignored. If the
`remote HTTP server does not support the condi-
`tional GET request no harm wil1 be done,
`the
`server wil1 just send the document
`in full. Fortu-
`nately al1 the major HTTP servers already sup-
`port the conditional GET header.
`The caching mechanism
`is disk based and per-
`sistent, which means
`it survives restarts of the
`proxy process as wel1 as the server machine itself.
`Because of this feature, caching opens up new
`possibilities when the caching proxy server and a
`Web client are on the same machine. The proxy
`can be configured
`to use only the local cache,
`making it possible to give demos without an inter-
`net connection. You can even unplug a portable
`machine and take it to the cafeteria.
`
`3. The future
`
`As the public enthusiasm for proxies has arisen
`just recently,
`there are many features
`that are
`stil1 in their early stages, though
`the basic func-
`tionality is already
`there. Caching
`is clearly a
`wide and complicated area, and it is one of the
`parts of the proxy server that needs to be greatly
`enhanced. The proxy could be enhanced
`to do
`lookahead, retrieving al1 documents
`that are likely
`to be accessed soon. For example, al1 the docu-
`ments referenced
`by a document
`that was re-
`quested recently, including al1 the inlined images.
`The HTTP protocol
`should be further
`en-
`hanced
`to allow multipart
`requests
`and
`re-
`sponses; this would allow both caching and mir-
`roring software
`to refresh
`large amounts of files
`in a single connection,
`rather
`than re-connecting
`to the remote server once for each file. Multipart
`messages are also needed by Web clients
`for
`retrieving al1 the inlined images with one connec-
`tion.
`Several aspects of the proxy architecture need
`to be standardized. A proxy server port number
`should be assigned by the Internet authority. On
`the client side there
`is a need
`for a fallback
`mechanism for proxies so that a client can con-
`neet to a second or third proxy server
`if the
`primary proxy failed (like DNS). Also a dynamic
`lookup method for finding the closest proxy server
`
`this might be achieved by using a
`is necessary;
`standard DNS name, for example w w w _ p r o x y .
`m y . dom a i n. This kind of dynamic host lookup is
`not just proxy-centric
`- Web clients should have
`the same kind of mechanism
`for finding a local
`home page, and the closest functional server in a
`set of servers mirroring each other.
`
`4. Conclusions
`
`Thanks to standard proxy support in the clients,
`and the wide availability of the CERN _HITPD proxy
`server, anyone behind a firewall can now have
`full Web access through
`the firewall host with
`minimum effort and without compromising secu-
`rity. Corporate users do not have to be denied
`access to the Web any longer.
`fast growth of the
`Considering
`the extremely
`Web, its ability to replace FTP, and the fact that
`by the time this paper is published the Web usage
`has already passed Gopher usage metered by the
`packet statistics in the network, the use of caching
`proxy servers becomes
`essential
`to allow
`the
`growth
`to continue
`in case
`the
`total
`Internet
`capacity does not keep up with the Web growth
`rate. The proxy caching makes it possible to gain
`“virtual bandwidth” as documents often get re-
`turned
`from a nearby cache
`rather
`than from
`some far away server.
`
`References
`
`[l] HyperText
`(URL:http://info.-
`Protocol.
`Transfer
`cern.ch/hypertext/WWWWW/Protocols/HTTP/Hm2.
`html).
`[2] J. Postel and J. Reynolds, File Transfer Protocol, Inter-
`net RFC 959, October 1985. (URL:
`ftp://ds.internic.
`net/rfc/rfc959&.
`[3] F. Anklesaria et al., The Internet Gopher Protocol, In-
`ternet RFC 1436, March 1993. (URL: ftp://ds.internic.
`net/rfc/rfc
`1436.66).
`[4] Wide-Area
`Information System.
`wais.com/z3950.html).
`[5] B. Kantor and Phil Lapsley, Network News Transfer
`Protocol,
`Internet RFC 977, February 1986. (URL:
`http://info.cem.ch/hypertext/WWW/Protocols/
`rfc977/&977.html).
`[6] Rob McCool, The Common Gateway Interface, 1993-
`1994. (URL: http://hoohoo.ncsa.uiuc.edu/cgi/).
`
`(URL: http://www.
`
`Juniper Ex. 1053-p. 7
`Juniper v Implicit
`
`

`

`1.54
`
`A. Luotonen, K Altis /Computer Networks and ISDN Systems 27 (1994) 147-154
`
`ArI Luotenen is writing his Master’s Thesis at CERN until the
`summer 1994 on the architecture of generic hypertext servers.
`He is studying software engineering and mathematics
`in Tam-
`pere University of Technology, Finland, and wil1 graduate in
`May 1995. His electronic mail address
`is luotonen@www.
`cern.ch.
`
`Kevin Akis is an Internet Program Architect at Intel Corpora-
`tions’ Media Delivery Laboratory
`in Hillsboro, Oregon. He is
`interested
`in PC oriented usage of multi-media
`information
`via the Internet. His electronic mail address
`is altis@beam.
`intelcom.
`
`(URL: http://info.cern.
`[7] Uniform Resource Locators.
`ch/hypertext/WWW/Addressing/Addressing.html).
`[SI The WWW Common Library. (URL: http://info.cern.
`ch/hypertext/WWW/Library/Status.html).
`[9] CERN hypertext daemon.
`(URL: http://info.cern.ch/
`hypertext/WWW/Daemon/Status.html).
`termi-
`[lol Lynx, a full-featured WWW client for character
`nals.
`(URL:
`http://www.cc.ukans.edu/
`lynx_help/
`Lynx_users_ guide.html).
`(URkhttp:
`[ll] NCSA Mosaic
`for X Window System.
`//www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/
`mosaic-docs.html).
`for Microsoft Windows.
`[12] NCSA Mosaic
`ttp://wvnv.ncsa.uiuc.edu/SDG/Software/WinMosaic/
`HomePage.html).
`[13] William Perry, The Emacs WWW Browser,
`htpp://moose.cs.indiana.edu/usr/local/www/elisp/
`w3/docs.html).
`(URL:http://info.
`as a proxy server:
`[14] CERN httpd
`cern.ch/hypertext/WWWWW/Daemon/User/Proxies/
`Proxies.html).
`in Mosaic for X: (URL: http://www.nc-
`[15] Proxy support
`sa.uiuc.edu/SDG/Software/Mosaic/Docs/proxy-gate-
`way-s.html).
`http://www.
`(URL:
`in WinMosaic:
`[16] Proxy support
`ncsa.uiuc.edu/SDG/Software/WinMosaic/ProxyInfo.
`html).
`
`(URL:
`
`(URL:
`
`Juniper Ex. 1053-p. 8
`Juniper v Implicit
`
`