`
`ISSN 0169-7552
`
`nd
`SDNS'l
`
`MS
`
`•
`
`· .. •.,.
`
`k
`
`Volume 27 (1994)
`Number 2
`November 1994
`
`t I ,--:c
`/'
`j.
`...... ~
`
`4
`
`I
`
`{t~•
`
`Special Issue
`
`Selected Papers
`of the First World-Wide Web Conference
`Guest Editor:
`R. Cailliau
`
`Netflix, Inc. - Ex. 1012, Page 000001
`
`IPR2021-01319 (Netflix, Inc. v. CA, Inc.)
`
`
`
`Contents
`
`Special Issue on Selected Papers of First World-Wide Web Conference
`
`Technology
`
`D. Raggett
`A review of the HTML + document format
`
`A. Luotonen and K A/tis
`World-Wide Web proxies
`
`E.D. Katz, M. Butler and R. McGrath
`A scalable HTTP server: The NCSA prototype
`
`S. Glassman
`A caching relay for the World Wide Web
`
`M. Koster
`ALIWEB - Archie-like indexing in the WEB
`
`P.M.E. De Bra and R.D.J. Post
`Information retrieval in the World-Wide Web: Making client-based search-
`ing feasible
`
`R. T. Fielding
`Maintaining distributed hypertext infostructures: Welcome to MOMspider's
`Web
`
`B. Rousseau and M. Ruggier
`Writing documents for paper and WWW
`
`N. Drakos
`From text to hypertext: A post-hoc rationalisation of LaTeX2HTML
`
`A. Whitcraft and T. Wilkinson
`A tangled Web of Deceit
`
`T. Takada
`Multilingual information exchange through the World-Wide Web
`
`Applications
`
`J. Pitkow and M. Recker
`Results from the First World-Wide Web user survey
`
`135
`
`147
`
`155
`
`165
`
`175
`
`183
`
`193
`
`205
`
`215
`
`225
`
`235
`
`243
`
`Netflix, Inc. - Ex. 1012, Page 000002
`
`
`
`vi
`
`B. Ibrahim
`World-wide algorithm animation
`
`M. Mascha and G. Seaman
`Interactive education: Transitioning CD-ROMs to the Web
`
`S. Putz
`Interactive information services using World-Wide Web hypertext
`
`D. Eichmann, T. McGregor and D. Danley
`Integrating structured databases into the Web: The MORE system
`
`A.F. Slater
`Controlled by the Web
`
`Business, Government and Press
`
`R. Jones
`Digital's World-Wide Web server: A case study
`
`Abstracts
`Other Papers Presented at the 1st WWW Conference
`
`Workshop Reports
`
`Calendar
`
`255
`
`267
`
`273
`
`281
`
`289
`
`297
`
`307
`
`317
`
`341
`
`Netflix, Inc. - Ex. 1012, Page 000003
`
`
`
`~
`
`I-,~
`
`,(cid:173)
`...
`EJ.SBVTER
`
`Computer Networks and ISDN Systems 27 (1994) 147-154
`
`COMPUTER
`NETWORKS
`and
`ISDN SYSTEMS
`
`World-Wide Web proxies
`
`Ari Luotonen a, Kevin Al tis b
`a CERN, Geneva, Switzerland
`b Intel, Hillsboro, Oregon, USA
`
`Abstract
`
`A WWW proxy server, proxy for short, provides access to the Web for people on closed subnets who can only
`access the Internet through a firewall machine. The hypertext server developed at CERN, cern_httpd, is capable of
`running as a proxy, providing seamless external access to HTTP, Gopher, WAIS and FTP.
`cern_httpd has had gateway features for a long time, but only this spring they were extended to support all the
`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.
`A brand new feature is caching performed by the proxy, resulting in shorter response times after the first
`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 [1] 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, th e same proxy is used by all
`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.
`The ability to cache documents also makes
`Proxies attractive to those not inside a firewall.
`
`·
`·
`Bis
`ev1er Science B.V.
`SSDJ 0169-7552(94)00064-6
`
`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 network 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 l 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 [10], made the
`first L i b w w w changes to support proxying in col(cid:173)
`laboration with Kevin Altis. Ari Luotonen main-
`
`Netflix, Inc. - Ex. 1012, Page 000004
`
`
`
`148
`
`A. Luotonen, KA/tis / Computer Networks and ISDN Systems 27 (1994) 147-154
`
`Gopher listings across clients rather than each '
`client having its own special handling.
`(
`A proxy allows client writers to forget about
`the tens of thousands of lines of networking COdc I
`necessary to support every protocol and concen. 1
`it is [
`trate on more important client issues -
`possible to have "ligblweight' clients that only
`understand H1TP (no native FTP (2], Gopher [3] \
`etc., protocol support) - other protocols ar~
`
`transparently handled by the proxy. By using
`HTTP between the client and proxy, no protoeol •
`functionality is lost, since FTP, Gopher, and other \
`Web protocols map well into HTTP methods.
`Clients without DNS (Domain Name Service) 1
`can still use the Web. The proxy IP address is the (
`only information they need. Organizations using
`private network address spaces such as the cla~ (
`A net 10. * . * . * can still use the Internet as long I
`as the proxy is visible to both the private internal l
`net and the Internet, most likely via two separate
`network interfaces.
`Proxying allows for high level logging of client
`transactions, including client IP address, date and
`time, URL [7], byte count, and success code. Any
`regular fields and meta-information fields in an I
`HTTP transaction are candidates for logging. This t
`is not possible with logging at the IP or TCP
`level.
`It is also possible to do filtering of client
`transactions at the application protocol level. The
`
`I
`
`1,
`
`tains the CERN h t t pd [9). Ari has made the
`server side of the proxy standard a reality and
`integrated caching into the proxy server.
`
`1.1. Why an application-leuel proxy?
`
`An application-level 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.
`For Web clients, the modifications needed to
`support application-level 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(cid:173)
`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(cid:173)
`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 all of these cases. The proxy
`also standardizes the appearance of FTP and
`
`Secure subnet inside 'firewall
`
`~~, HTTP
`firewall
`
`Pro~r:er
`firewall
`machine
`
`Fig. 1. Overall setup of a proxy. Proxy server is running either on a fi rewall host or other internal host which has full [Ill~
`access, or on a machine inside the firewall making connections to the outside world through SOCKS or other firewall softW
`
`WAIS
`servers
`
`Netflix, Inc. - Ex. 1012, Page 000005
`
`
`
`A . Luotonen, K Allis/ Computer Networks and ISDN Systems 27 (1994) 147-154
`
`149
`
`client
`
`GET /path/doc.html HTTP/1.0
`
`-~
`
`some.host
`
`HTTP
`server
`
`HTTP
`
`-
`~ --
`
`--
`
`I
`HTTP/1.0 200 Documentfollows Web
`
`/d~
`
`Remote HTTP
`server's fifesystem
`
`, F' ? A normal HTI'P transaction. Client makes a request to
`1g. ~
`the f!1TP server and specifies the requested resource relative
`10 that server (no pro tocol or hostnarnc specifier in the URL).
`
`r, proxY can control access to services for individual
`methods, host and domain, etc.
`Application-level 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
`i, 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 external 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-
`
`motely, but may be cached locally. Also, one
`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(cid:173)
`son to use firewall versions of their code. In the
`case of the application-level proxy, they have an
`incentive, since the proxy provides caching. De(cid:173)
`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 all
`platforms, not just Unix.
`
`2. Technical details
`
`When a normal HTTP request is made by a
`client, the HTTP server gets only the path and
`keyword portion of the requested URL (Fig. 2);
`other parts, namely
`the protocol specifier
`"h t t p:" and the hostname are obviously clear to
`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 CGI [6] script on the local filesys(cid:173)
`tem of the server, or some other resource avail(cid:173)
`able from that server.
`When a client sends a request to a proxy
`server the situation is slightly different. The client
`always uses HTTP for transactions with the proxy
`server, even when accessing a resource served by
`
`some.host
`GET http://some.host/pafh/doc.html KTTP/1.0 GET /path/doc html HTTP/l O
`
`www_proxy.my.domoin
`
`Client
`
`HTTP
`
`-~
`
`..... -
`
`Proxy
`server
`
`HTTP
`
`~
`
`~
`
`-
`-
`
`HTTP
`server
`
`\
`
`~:~:;;;;;;;:~;y,do~=~~~ ~c,-atro23
`
`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 seiver (no protocol or hostname specifier in the
`DRL).
`
`Netflix, Inc. - Ex. 1012, Page 000006
`
`
`
`150
`
`A . Luotonen, KA/tis / Computer Net1Vorks and ISDN Systems 27 (1994) 147-154
`
`a remote server using another protocol, like Go(cid:173)
`pher or FTP.
`However, instead of specifying only the path(cid:173)
`name and possibly search keywords to the proxy
`server, the full URL is specified (Figs. 3 and 4).
`This way the proxy server has all the inform_ation
`necessary to make the actual request to the re(cid:173)
`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 l i b w w w that the client would
`call to perform the retrieval. However, the "pre(cid:173)
`sentation" on the proxy actually means the cre(cid:173)
`ation of an HTTP 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 l i b(cid:173)
`w w w, the WWW Common Library, which handles
`the different communication protocols used in
`the Web, namely HTTP, FTP, Gopher, News [5]
`and WAIS [4].
`The entire proxy support is handled automati(cid:173)
`cally for clients using the L i b w w w. Environment
`variables are used to control the library. There is
`an individual environment variable for each ac(cid:173)
`cess protocol; e.g., h t t p _Proxy, f t p _Proxy ,
`go p he r _Proxy and w a i s _Proxy. These vari(cid:173)
`ables are set to the URL pointing to the proxy
`
`www_proxy.my.domain
`
`r
`server that is supposed to serve requests of th '
`I .
`1
`protoco , e.g.
`,
`ftp _Proxy = http : / / w w w _Pro x Y . do ma; n: I
`911 / export ftp _Proxy
`Usually the proxy server is the same for all the
`protocols, but does not have to be.
`When the environment variable for a given
`protocol is set, the L i b w w w code causes a con(cid:173)
`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 [11]
`can use X resources and Mosaic for Windows [12] 1
`uses settings in its initialization file).
`The latest (as of April 1994) Li bwww (version
`2.15) also supports an exception list so clients do
`not always have to go through the proxy. This~
`useful for avoiding the proxy for local servers
`where the clients can make a direct connection.
`Another difference 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(cid:173)
`ences between a normal and proxied HTTP
`transaction. The simplicity of proxy support in a
`Web client means that even clients not based on
`L i b w w w can easily support the proxy.
`Proxy support
`is
`implemented only for :
`HTTP / 1.0 on the server side so clients use that
`protocol. This is not a problem because l i bwww
`does this automatically, and most clients (if not '
`to use
`all) have already been upgraded
`HTTP/ 1.0.
`
`Client
`
`GET ftp://some.host/path/doc.hlml HTTl'/1.0
`,...
`
`-
`
`Proxy
`server
`
`HTTP
`
`~
`
`~
`
`HTTP/.1.0 200 Document follows
`
`st
`some.ho
`FTP
`server
`
`FTP request -
`-
`FTP
`-- FTP response
`
`ftp:! / some.host / path/ doc .htm l
`ftp_proxy=http:// Vl\,VW_proxy. m y.domain/
`
`·s
`Fig. 4. A proxied FTP transaction. Client makes a request to the proxy server, using HTTP, even though the actual resoi;t:fi!e
`served by an FTP server. The proxy server sees from the full URL that an FTP connection should be made, and retrieves t
`from the remote FfP server. Result is sent back to the client using HTTP.
`
`Netflix, Inc. - Ex. 1012, Page 000007
`
`
`
`A. Luotonen, K. A/tis /Computer Networks and ISDN Systems 27 (1994) 147-154.
`
`151
`
`Server side issues
`
`server for multiple protocols since the client al(cid:173)
`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(cid:173)
`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.
`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 ht t pd -
`this means that the
`proxy server does not have to run on the fire(cid:173)
`wall 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 all the FTP servers support P ASV 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.
`
`2.2-
`'fhe proxY erver has to be able to act as both
`rver and a client. It is a server when accepting
`~p requests from clients connecting to it, but
`. cts ti.Ice a client to the remote servers that it
`it ~ects to in order to actually retrieve the docu(cid:173)
`cO nts for its own clients. The header fields passed
`rne the proxy from the client are used without
`toodification when the proxy connects to the re(cid:173)
`Jl'l ote server so that the client does not lose any
`~ctionality when gojng through a proxy.
`A complete proxy erver should speak all the
`f/ Web protocols, the most important ones being
`/ J:ffTP, FTP, Go_pher, WAIS and NNTP. Proxies
`I 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
`l to handle the remaining protocols.
`CERN ht t pd, whicb is one of the HTIP
`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
`
`l
`
`r
`
`l HTTP servers which only understand the HTTP
`
`protocol, CERN ht t pd is able to speak all of the
`•·· Web protocols just like Web clients can as all the
`protocols are implemented by Li bwww.
`CERN h t t pd has been able to run as a proto(cid:173)
`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-
`t sion 2.15, the server was enhanced to accept full
`URLs. The same server can now act as a proxy
`
`GET full-URL HTTP /1.0
`
`Client
`
`HTTP
`
`---
`
`Proxy
`server
`
`www_proxy.my.domain
`
`Request
`
`Any supported protocol
`
`some.host
`Remote
`server
`
`HlTP/1.0 200 Document follows
`--r-....
`
`Response
`
`Fig. 5. A caching proxy. The requested document is retrieved from the remote server and stored locally on the proxy server for later
`use.
`
`Netflix, Inc. - Ex. 1012, Page 000008
`
`
`
`152
`
`A. Luotonen, K. A/tis/ Computer Networks and ISDN Systems 27 (1994) 147-154
`
`2.3. Caching
`
`The basic idea in caching is simple: store the
`retrieved document into a local file for further
`use so it won't be necessary to connect to the
`remote server the next time a document is re(cid:173)
`quested (Figs. 5 and 6).
`However, there are many problems that need
`to be coped with once caching is introduced. How
`long is it possible to keep a document in the
`cache and still be sure that it is up-to-date? How
`to decide which documents are worth caching
`ahd for how long?
`Document expiry has been foreseen in the
`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 will have to rely on
`other, more heuristic approaches, like only mak(cid:173)
`ing a rough estimate of the time to live for an
`object.
`More importantly, since many of the docu(cid:173)
`ments in the Web are "living" documents, speci(cid:173)
`fying an expiry date for them is generally a diffi(cid:173)
`cult task. A given document may remain un(cid:173)
`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
`
`When it is essential that the retrieved docu(cid:173)
`ment is up-to-date, it is necessary to contact the
`
`remote server for each GET request. The ffrtr> :
`protocol already contains the HEAD method fo ,
`retrieving a documents' beader information, bu:
`not the document itself. This is useful for check.
`ing if the document has been modified since the ,
`last access.
`However, in ca es where the document has
`changed it wou1d be very inefficient to rnake 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.
`The HTTP protocol was therefore extended to
`contain an If- Modified- Since request
`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 1
`(proxy cache) was last modified.
`If the document has not been modified since
`the date and time specified it will not be sent
`back, instead only the relevant object meta-infor(cid:173)
`mation headers, such as a new expiry date will be
`returned, along with a special result code. If the
`document has been modified it will 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(cid:173)
`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(cid:173)
`ment is explicitly requested.
`Jt is worth noting that the conditional GET
`header i backward compatible. HrrP is defined
`
`www_proxy.my.domain
`
`GET full-URL HTTP/1.0
`
`Client
`
`HTTP
`
`Proxy
`server
`
`HTTP/1.0 200 Document follows
`
`some.host
`Remote
`server
`
`Fig. 6. Cache hit on the proxy. If an up-to-date version of the requested document is found in the cache of the proxY server no
`connection to the remote server is necessary.
`
`Netflix, Inc. - Ex. 1012, Page 000009
`
`
`
`A. Luoto11en, K Altis / Computer Networks and ISDN Systems 27 (1994) 147-154
`
`153
`
`,
`
`.,
`
`that unknown header fields are ignored. lf the
`so ote JITTP server does not support the condi(cid:173)
`r~;al GITT request no harm will be done, the
`0 rver will just send the document in fu.U. Fortu(cid:173)
`se tely aU the major HTTP servers already up(cid:173)
`na rt tbe conditional GET header.
`po fbe caching mechanism is disk based and per(cid:173)
`sistent, which means it survives re tarts of the
`roxY process as well as the server machine itself.
`~ecause of this feature, caching opens up new
`p0ssibilities when the caching proxy seiver and a
`Web client are on the same machine. The proxy
`can be configured to use only U1e local cache
`1Jlaking it possible to give demos without an inter(cid:173)
`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
`still in their early stages, though the basic func(cid:173)
`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 all documents that are likely
`to be accessed soon. For example, all the docu(cid:173)
`ments referenced by a document that was re(cid:173)
`quested recently, including all the inlined images.
`The HTTP protocol should be further en-
`hanced
`to allow multipart requests and re(cid:173)
`sponses; this would allow both caching and mir(cid:173)
`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 all the inlined images with one connec(cid:173)
`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(cid:173)
`nect 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
`
`is necessary; this might be achieved by using a
`standard DNS name, for example www_proxy.
`my • do ma 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 _HTIPD proxy
`server, anyone behind a firewall can now have
`full Web access through the firewall host with
`minimum effort and without compromising secu(cid:173)
`rity. Corporate users do not have to be denied
`access to the Web any longer.
`Considering the extremely fast growth of the
`Web, its ability to replace FfP, 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(cid:173)
`turned from a nearby cache rather than from
`some far away server.
`
`References
`
`( URL:http:/ / info.(cid:173)
`[1] HyperText Transfer Protocol.
`cern.ch/ hypertext/ WWW / Protocols/ HTTP / HITP2.
`html) .
`[2] J. Postel and J. Reynolds, File Transfer Protocol, Inter(cid:173)
`net RFC 959, October 1985. (URL: ftp: / /ds.internic.
`net/rlc/rfc959.txt) .
`[3] F. Anklesaria et al., The Internet Gopher Protocol, In(cid:173)
`ternet RFC 1436, March 1993. ( URL: ftp:/ / ds.internic.
`net/ rfc/ rfc 1436.txt) .
`[4] Wide-Area Infonnation System. (URL: http:/ / www.
`wais.com/z3950.html) .
`[5] B. Kantor and Phil Lapsley, Network News Transfer
`Protocol, Internet RFC 977, February 1986. ( URL:
`http:/ / info.cern.ch/ hypertext/ WWW / Protocols/
`rfc977 / rfc977.html) .
`[6] Rob McCool, The Common Gateway Interface, 1993-
`1994. (URL: http:/ /hoohoo.ncsa.uiuc.edu/cgi/ ).
`
`Netflix, Inc. - Ex. 1012, Page 000010
`
`
`
`154
`
`A. Luotonen, KA/tis / Computer Networks a11d ISDN Systems 27 (1994) 147-154
`
`Ari Luotonen is writing his Master's Thesis at CERN until th
`summer 1994 on the architecture of generic hypertex1 serve:
`He is studying software engineering and mnthcmalics in Tam:
`pere University of T echnology, F inland, and will graduate in
`May 1995. His electronic ma il address is luotoncn@wv.w,
`cem.ch.
`
`Kevin Allis is an Internet Program Architect at Intel Corpora(cid:173)
`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.
`in tel.com.
`
`[7] Uniform Resource Locators. (URL: http: / / info.cern.
`ch/ hypertext/ WWW/ Addressing/ Addressing.html).
`[8] 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 ).
`[lCl] Lynx, a full-featured WWW client for character termi(cid:173)
`nals.
`( URL: http:/ / www.cc.ukans.edu/ lynx_help/
`Lynx _users_ guide.html).
`[11] NCSA Mosaic for X Window System. ( URL:http:
`/ / www.ncsa.uiuc.edu/ SDG/ Software/ Mosaic/ Docs/
`mosaic-docs.html).
`(URL:
`for Microsoft Windows.
`[12] NCSA Mosaic
`ttp://www.ncsa.uiuc.edu/ SDG / Software / WinMosaic /
`HomePage.html).
`[13] William Perry, The Emacs WWW Browser, (URL:
`htpp:/ / moose.cs.indiana.edu / usr / local/ www /elisp/
`w3/ docs.html) .
`[14] CERN httpd as a proxy server: (URL:http:/ / info.
`cern.ch/hypertextjWWW / Daemon / User / Proxies/
`Proxies.html).
`[15] Proxy support in Mosaic for X: (URL: http: / / www.nc(cid:173)
`sa.uiuc.edu/ SDG / Software/ Mosaic / Docs / proxy-gate(cid:173)
`way-s.html).
`in WinMosaic: (URL: http:/ / www.
`[16] Proxy support
`ncsa.uiuc.edu/ SDG/ Software/ WinMosaic/ Proxylnfo.
`html) .
`
`Netflix, Inc. - Ex. 1012, Page 000011
`
`