PRENTICE HALL PTR WEB INFRASTRUCTURE SERIES
`
`WEBPROXY
`SERVERS
`
`From the Chief
`Architect
`nf thg Nạtcrane
`
`Co-Developer
`of the CERN
`Proxy Server
`
`Thorough Coverage
`of Proxy
`Network Design,
`Management,
`and Optimization
`
`4:bam
`O
`
`aommn:Pn
`
`Sinrtimor
`
`ARI LUOTONEN
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 1
`
`

`

`..m.•.•••
`
`•••••=2/1MSATIIN•00 ,11.,CIL
`
`•
`
`•
`
`re Web Proxy
`Servers
`
`„,.
`
`it
`
`iL
`
`.1•7441.4
`
`e
`
`LY
`
`t;
`
`14
`
`01=
`
`Ari Luotonen
`Paul Mockapetris, Series Advisor
`
`To join a Prentice Hall PTR Internet mailing list, point to
`http://www.prenhall.com/mail_lists/
`
`Prentice Hall PTR, Upper Saddle River, NJ 07458
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 2
`
`

`

`Library ofCongress Caraloging-in-Publication Date
`
`Luotonen, Ari.
`Web proxy servers/ Ari Luotonen.
`cm.-(Web infrastructureseries)
`p.
`Includes bibliographical references and index.
`ISBN: 0-13-680612-0 (alk. paper)
`1. Web servers.
`2. Title.
`II. Series.
`TKS105.388.L86
`1997
`005.7"1376 dc21
`
`Editorial/Production Supervision: Kathleen M. Caren
`Acquisitions Editor: Mary Franz
`Editorial Asistant: NoreenRegina
`Series Advisor: Paul Mockapetris
`Marketing Manager: Miles Williams
`Buyer: Alexis Heydt
`Cover Design: Anthony Gemmellaro; Illustration: Leonardo da Vinci
`Cover Design Direction: Jerry Votta
`Series Design: Meg Van Arsdale
`Art Director: GailCocker-Bogusz
`
`O 1998 Netscape Communications Corporation
`Published by Prentice Hall PTR
`EPrentice-Hall,
`Inc., ASimon &SchusterCompany
`Upper Saddle River, NJ 07458
`
`97-40619
`CIP
`
`Prentice Hall books are widley used by permission by corporations and government agencies for training,
`marketing, andresale.The publisher offers discounts on this book when ordered in bulk quantities.
`For more information, contact:
`
`Corporate Sales Department,
`Prentice HallPTR
`One Lake Street
`Upper Saddle River, NJ 07458
`Phone: 800-382-3419; FAX: 201-236-714
`E-mail (Internet): corpsales@prenhall.com
`
`09noio:J iA
`
`Allrightsreserved.Nopartofthisbookmaybereproduced,inanyform
`or by anymeans, without permission in writing from the publisher
`
`21susdbuv
`
`u
`
`Printed in the United States of America
`10 9876543 21
`
`oon.fsmenlTLiloff seHodet
`
`ISBN 0-13-680612-0
`
`Prentice-HallInternational (UK) Limited, London
`Prentice-Hall of Australia Pry. Limited, Sydney
`Prentice-HallCanada Inc., Toronto
`Prentice-Hall Hispanoamericana, S.A., Mexico
`Prentice-Hall of India Private Limited, New Delhi
`Prentice-HallofJapan, Inc., Tokyo
`Simon & SchusterAsiaPre. Ltd., Singapore
`Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 3
`
`

`

`CHAPTER 4
`
`The HTTP Protocol
`
`the
`This chapter provides an overview and reference of
`HyperText Transfer Protocol, commonly referred to as HTTP.
`Aspects related to proxy servers are emphasized. Some fea-
`tures not related to proxy servers have been omitted. While
`the World Wide Web consists of, and is built on top of, a
`plethora of different protocols, HTTP is the primary protocol
`used for transferring Web documents. Other common Inter-
`net protocols related to the Web and proxying are discussed
`throughout the rest of this part of the book.
`
`39
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 4
`
`

`

`40
`
`Web Proxy Servers
`
`The first sections of this chapter are an overview of the mainaspects
`of the HTTP protocol and are recommended reading in order tounder-
`stand how HTTP works. The last three sections are a complete list ofoff-
`cial HTTP request methods (the section on HTTP request methodson
`page 64), headers (the section on
`HTTP
`headers on page 69, and
`response status codes (the section on HTTP response status codeson
`page 96). Those sections may be arduous reading. Dont
`feel guilty about
`skipping them--but
`they may become handy as a reference to HTTP ata
`later time.
`
`OVERALL OPERATION OF HTTP
`
`to the
`HTTP is a request/response protocol. The client sends a request
`server, and the server sends back a response. There are no multiple-step
`handshakes in the beginning as with some other protocols, such as FT?
`There may be intermediate proxy servers between the client and the
`server; the client may send a request
`to the proxy serve, and the proxy
`will
`forward the request to the server, or another proxy. This is called a
`request chain. The response comes back through
`he same path,
`the
`response chain.
`Intermediate proxy servers may cache resources and may
`return acached copy without
`forwarding the request to the origin server.
`An HTTP requestconsists of a method, a target URL, protocol version
`identifier, and aset ofbeaders.The method specifies the type of operation.
`The most common method is GET, which is used to retrieve documents.
`POST isused to perform HTML form submissions. The section on HTTP
`requestmechodson page 64 describes the methods in moe detail. Headers
`containadditional information to the equest; the section on HTTP head-
`ers on page 69 lists all currently defined HTTP headers.
`An HTTP responseconsists of a protocol version identifier, status
`code, human-readable response status line,
`response headers, and the
`requested resource content. Status codes are listed and described in che
`section on HTTP responsestatus codes on page 96.
`.Extensive examplesof the actual protocol areshown in the following
`sections.But first, let'sstep back and look at the history and evolution of
`HTTP
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 5
`
`

`

`4
`
`The HTTP Protocol
`
`41
`
`oaleaLL
`
`DESIGN GOALS OF HTTP
`The HTTP protocol wasdesigned with simplicity, extensibility, compati-
`bility, and speed in mind. The goal was to make it easy to implement and
`debug applications that use HTTP as their
`communication protocol.
`Another
`important
`factor was to make it suitable for a global hypermedia
`information system, which had some definite requirements on the proto-
`col. The following sections provide more insight into these design goals.
`Simplicity
`text protocol. Unlike binary protocols which are
`HTTP is a simple ASCII
`hard todebug, HTTP caneasilybedebuggedbysimplyusingthe tel-
`net program to connect
`to the proxy server port and mimicing the
`HTTP protocol by hand (see Chapter 22 on troubleshooting).
`The first version of HTTP later given the version number 0.9, was
`very simple; the request simply contained the request methodin
`prac-
`tice always GET-and
`the URL of
`the document
`that was being
`requested,
`followed by a<ooct> [1]:
`GET URL <c<lf>
`HTTP/0.9 supports only plain retrieval of documents, with no access
`control, or any other fancy features. The response simply contains the
`requested document, with no other
`information. The connection is
`closed immediately after the document
`transfer is complete.
`Extensibility
`The HTTP/1.0 version introduced request and responseheaders.Headers
`allowed the HTTP protocol
`to be extended in a flexible manner.
`It was
`now posible to send authentication credentials, state information, con-
`tent negotiation directives, and other data that could be used in the con-
`text of request processing. The response would no longer depend solely
`on the requested URL, but possibly on the other
`information pased in
`the headers, such as the user's identity, or
`the client software version.
`Users could now get customized pages tailored specifically for them and
`their client software.
`Compatibility
`When designing a global application used by millions of people, compat-
`ibility with different protocol versions is of utmost importance.Packaged
`
`t
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 6
`
`

`

`42
`
`Web Proxy Servers
`
`applications targeted toward single companies may get away withchang:
`ing their protocol between releases in an incompatible mannerbecuse
`the upgrade can be done for all users at once. However,
`in a globalscale
`deployment with multiple client and server software vendors,interopera-
`bility between different protocol versions is required.
`The HTTP specification has provisions for supporting olderversions
`of the protocol, as well as ignoring new features that are not known by
`the current protocol.
`Lightweight
`documents faces certain
`hypertext
`transferring
`A protocol used for
`requirements. Hypertext documents consist of text
`that containspoint-
`ers, or hypertext
`links,
`to other documents. The nature of the systemis
`such that a fast document
`transfer is followed by a fairly long period of
`inactivity--while the user is reading the document. After a while, theuser
`will click on a link, which initiates a new retrieval.
`This natureimposes the following requirements:
`• Theoverhead of the protocol must be minimal
`fast interactive performance.
`It must be fast to establish a connection to a hypertext server.
`• Connection should not remain open while the user is reading the
`document.
`
`in order to provide
`
`These criteria were met fairly well by HTTP/O.9 and HTTP/1.0. How-
`ever,as the Web developed, more embedded data appeared on pages, such
`as inlined images andJava applets. Each of these cause their own HTTP
`request, and the page load no longer mapped to a single HTTP request;
`instead, there would beseveral. This gavė rise to the need for more effi-
`cient transport, in the form ofpersistentconnections (see the section on
`HTTP persistentconnections (keep-alive) on page 47), and later possibly
`as a multiplexing protocol (see the section on Muliplexed Sessions on
`page 50).
`
`HTTP/0.9
`
`As previously stated, the first version of HTTR referred to as HTTP/0.9,
`was very simple: it supported only a single method, GET This first ver-
`sionwas sufficient for retrieving documents, but it provided no authenti-
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 7
`
`

`

`4
`
`The HTTP Protocol
`
`43
`
`cation or access control features other than those based on the IP address
`and the DNS host and domain names of the requesting client. The
`HTTP/0.9 response contained only the requested document, with no
`additional information.
`Document Typing
`The typing of documents in HTTP/0.9 wasbasedon the filename exten-
`sion present
`in the URL. This task was performed by HTTP/0.9 cli-
`ents-the server had no way of communicating the document type to the
`client. Later, the introduction ofheaders in HTTP/1.0 made it possible
`to have the document
`type be determined by the server and passed to the
`client in the
`Content-Type:
`header(scepage 94).
`In HTTP/0.9,
`the extension
`.html
`in the URL indicated an
`HTML document [2], .
`txt a plain textdocument,
`.gif animage in
`GIF format, and .jpg
`an image in JPEG format. The client had to
`inspect
`the URL to find out
`this information. This method was also
`prone to error since some files would not have any extension. Clients
`would have to "guess" the type, and even though it wassuccessful most of
`the time,
`there would be cases where the client guessed wrong, and the
`result was garbled.
`HTTP/1.0 changed the document typing paradigm; it was moved to
`the serve, and the clients were not allowed to look at the URL flename
`extension. This enabled theservers to have full control over the document
`typing and freed the naming scheme from the Web requirements. That is,
`servers could freely implement
`their own typing system--often it is based
`on the flename extensions, but nothing prevents other mechanisms.
`
`HTTP/1.0
`
`is documented in the Informational RFC 1945
`The HTTP/1.0 protocol
`itled "HypertextTransfer Protocol--HTTP/1.0."
`requests and
`for
`HTTP/1.0
`introduced a new, extended format
`responses allowing more data to be passed in both directions. After the
`actual request, a set of header fields follow. These are simple name-value
`pairs which allow additional
`information, such as authentication cRden-
`tials,
`to be passed to the server. The HTTP header section is similar to
`Multipurpose Internet Mail Extensions (MIME).
`the response also
`Similarly,
`in addition to the document content,
`includes a status line and its own header section. The response header sec-
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 8
`
`

`

`44
`
`Web Proxy Servers
`
`the document (the
`such as the type of
`information
`tion can contain
`Content-Length: header)and its length
`(Content-Length:).
`Another addition was the introduction of two new methods tocom-
`plement GET: HEAD for querying only the header
`information ofthe
`documentand POST which enabled HTML form submissions(3].
`An HTTP/1.0 style request
`for a URL, say
`http://wwW.some-
`site. com/somedirIpage.btmllooks like this:
`GET /somedir/page. html HTTP/1.0cor>if>
`Üser-agent:Mozilla/4.0<creif>b
`ot 3ri
`Accept:
`text/html,
`image/gif,
`image/jpeg<c>d>
`<c<lf>
`Theresponselookssomethinglike this:inhest
`ts
`HTTP/1.0 200 Ok<cr<lf>
`0corsclf>
`Server:
`Netscape-Enterprise/3.
`Date: Sat, 26 Apr 1997
`06:03: 24 GMTor>dits
`Content-type:
`text/htnl<cocdf >
`Content-1length:
`5361<cr>clf>
`<c><lf>
`.. documentcontent..
`HTTP/1.0 Proxy Servers
`The HTTPspecification[RFC1945]definesthe term proxy" asfollows:
`An intermediary program which acts as both a server and a
`client for thepurpose of making requests on behalf of other
`clients. Requestsare serviced internally or by passing them,
`with possibletranslation, on to other servers. A proxy must
`interpret and, if necessary, rewrite a request message before
`forwarding it.
`network
`Proxies are often used as client-side portals through
`irewalls and as helper applications for handling requests via
`protocols not implemented by the user agent.
`The simplest case of HTTP is when the connection is established
`directly from the client to the origin server. However,
`in practice this is
`often not the case. Instead, the request is made through one or more
`intermediary proxy servers. The general case is that
`there are numerous
`proxies in between the client and the origin server.
`Furthermore, a proxy server may have a cache where it stores com-
`monly accessed documents so that a given request might not actually
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 9
`
`

`

`4 The HTTP Protocol
`
`45
`
`HTTP/1. 0
`
`even go all the way to the origin server but instead be satisfied by a proxy
`server's cache, by reusing an carlier response to an equivalent request.
`The HTTP specification [RFC 1945] definesthe term "cache as follows:
`A program's local store of response messages and the sub-
`system that controls its message storage, retrieval, and dele-
`tion. A cache stores cacheable responses in order to reduce
`the response time and network bandwidth consumption on
`future, equivalent requests. Any client or server may include
`a cache,
`though a cache cannot be used by a server while it is
`acting as a tunnel.
`In other words, caching is not merely a feature of a proxy server. Cli-
`ent programs often have their own caches. Surprisingly, even origin serv-
`ers may use caching for their internal purposes. For example, busy origin
`servers may cache the generated header section and reuse the same head-
`ers for equivalent requests over and over again, instead of reconstructing
`them every time.
`Differences in the Use of HTTP
`In addition to client/server communication, HTTP is used between cli-
`ents and proxy servers, as well as between proxies and other proxies. But
`there is an important
`difference between a request made direcly to an
`origin server, and one made through a proxy:
`the requested URL is used
`in its full form, including the protocol prefx, hostname, and the optional
`port number. They are omitted when the request is made directly to the
`origin server
`[4]. For example, a request
`for
`the URL
`http://
`home.netscape.
`com/people/ari/
`from a client
`to a proxy
`server would look like this (the <ocit> are not shown in this example any-
`more -however,
`there is always an empty line terminating the header sec-
`tion):
`http://home.netscape.com/people/ari/
`GET
`User-agent: Mozilla/4.0
`image/jpeg
`Accept :
`text/html,
`image/gif,
`but when forwarded to the origin server by the proxy,
`rewritten to include only the URL path part:
`GET
`/people/ari/
`HTTP/1.0
`User-agent: Mozilla/4.0
`image/jpeg
`Accept:
`text/html,
`image/gif,
`Forwarded: by
`http://proxy. mycompany.com:8080
`
`the request
`
`is
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 10
`
`

`

`46
`
`Web Proxy Servers
`
`proxy servers may add the Forwarded:
`Note also that HTTP/1.0
`header
`indicating that
`the request passed through a proxy, althoughthe
`HTTP/1.0 specification does not mention that;
`it was not includedin
`the final specifcation, and HTTP/1.1 deprecates it by introducingthe
`Via: headerfor thatpurpose.
`to anotherproxy
`Of course,
`if a proxy server forwards the request
`server, the full URL is retained. Only the last proxy in the proxychain,
`connecting directly to the origin server, will drop the protocol, host,and
`optional port part of the URL.
`Sidebar
`transparent proxy servers (see the section on
`In the case of
`Transparent Proxying on page 14), it is clearly not possible
`to know if there are any more proxy servers downstream.
`The requestmayberedirectedto atransparentproxyserver
`by routers. However,
`in this scenario many things do not
`work according to the HTTP/1.1 specification (which makes
`no provisions for transparent proxies).
`
`Backward Compatibility
`The HTTP/1.0 specification requires backward compatibility by clients
`and server to interoperate with HTTP/0.9. HTTP/1.0 servers must rec-
`ognize both HTTP/0.9 and HTTP/1.0 requests and respond with the
`same protocol version. HTTP/1.0 clients must recognize both HTTP/
`0.9 and HTTP/1.0 responses [5].
`Protocol Upgrading and Downgrading
`Proxyservers that havea lower protocol version than the requesting client
`must downgrade the request to match the version of the proxy. This is
`becausethe request protocol version number indicates the level of capa-
`bilities of the sender (in this case the proxy), so the origin server must be
`notified about what version the proxy server it is talking to.
`Proxy servers with a higher protocol version than the requesting cli-
`ent may upgrade the request before forwarding it, but, naturally,
`they
`need to downgrade the receivedresponse to the level of the client.
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 11
`
`

`

`U
`
`bs
`
`S8 2
`
`4
`
`47
`
`The HTTP Protocol
`heeel
`al
`THEHTTP/1.1PROTOCOL
`The HTTP/1.1 specification is the Standards Track RFC 2068 itled
`"Hypertext TransferProtocol
`-HTTP/1.1." The major improvements in
`HTTP/1.1 over version 1.0 are
`Persistent connections.
`(see the section on HTTP persistent connec-
`utions
`on page47) HTTP/1.1 allows connections to remain open over
`several requests [6].
`(seepage 53) Together with persistent connections,
`Request pipelining.
`request pipelining reduces latency between requests and responses and
`2 deliversbetterperceivedperformance.
`Cache control. (the sections on HTTP/1.1 Cache Control Terminology
`on page 173 and HTTP/1.1 Cache Control on page 176) One of the big-
`gest missing features in HTTP/1.0 is theabsence of an explicit cache con-
`trol mechanism. HTTP/1.1 introduces a variety of directives that can be
`used to control caching onproxiesand in clients.
`Formalized
`validation model
`(conditional
`requests). (see page 158)
`HTTP/1.0 mentioned only the conditional GET feature as a mechanism
`to perform up-to-date checks. HTTP/1.1 formalizes the HTTP valida-
`tion model and provides opaque validators (see page 95), instead of just
`the last modification date and time used by HTTP/1.0.
`Content variants. (seepage 88) HTTP/1.l provides the basic utilities for
`associating multiple representations of a resource under a single URL.
`This is useful when providing a resource in multiple languages or differ-
`ent data formats.
`(see the section on HTTP tracing on page 370)
`Protocol
`tracing.
`HTTP/1.1 specifies a new method, TRACE, which is useful in debugging
`proxy chains (see the section on proxy chaining on page 22).
`
`3 7
`dt b
`
`HTTP PERSISTENT CONNECTIONS (KEEP-ALIVE)
`HTTP is a simple request-response protocol.
`In basic HTTP/1.0, each
`request
`is made over a new connection. After
`the data transfer
`is com-
`plete,
`the connection is torn down, and a new one is established to get
`another resource from the same server.
`there is a fair amount of
`Due to TCP's three-way handshake [7]
`latency in establishing each new connection. Therefore it would be bene-
`ficial to reusethe TCP connections to make multiple HTTP requests over
`a single connection. For this reason, an extension to the HTTP/1.0 pro-
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 12
`
`

`

`48
`
`Web Proxy Servers
`
`dt
`
`b
`
`b
`
`tocol was made, the so-called keep-alive feature. Figure 4.1 illustratesone
`shot requests compared to persistent connections used to peform severl
`requests.
`
`feature allows the samecon-
`connection)
`The keep-alive (persistent
`nection to remain open for multiple requests. Obviously,
`thedrawbackis
`that the next request processing cannot start before the previousresponse
`has been sent by the server.
`it is a flow control
`TCP also has a feature called slow-start. Basically,
`mechanism that slows down the speed at which data is sent until the po-
`tocol determines how fast
`the network
`link between the sender and
`receiver is. This mechanism is designed to prevent bogging down the net-
`work by shoving down as much data as possible, only to realize that the
`PIpeis not bigenoughanddeprivingotherapplicationsofthenetwodk
`bandwidth that they need. In other words, due to slow-start, a TCP con-
`nection takes a fair amount of time to reach full
`throughput.
`In thecase
`of HTTP with its short-lived connections,
`the slow-start makes the
`HTTP transactions take longer
`for small fles, and they speed up for
`larger fles. Using the persistent connection feature alleviates this problem
`as well.
`Persistent Connections in HTTP/1.0
`b
`The keep-alivefeature in HTTP/1.0 is invoked by the client first sending
`the following header in the request:
`Connection: keep-alive
`and if the serversupports this feature, the server will respond with the
`same header in its response:
`Connection: keep-alive
`After that, the server will not close the connection which is the default
`behaviorupon completion of datatransfer, but instead it leaves the con-
`nection open and waits for the next request to come over the same con-
`nection.
`Persistent Connections in HTTP/1.1
`it
`In HTTP/1.1,
`the persistent connection feature changed so that
`becamethe default. The client and server must now explicitly specify if
`they do not want persistent connections by sending the header
`Connection: close
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 13
`
`

`

`4
`
`The HTTP Protocol
`
`49
`
`Open
`connection
`
`Send
`request
`
`Receive
`response
`
`Read
`request
`Send
`response
`
`Client
`
`Figure 4.1
`
`Close
`connection
`Open
`Connection
`Sendnext
`request
`.
`..
`etc
`a) HTTP without persistent connections. Each request is made over a new
`connection.
`
`Read
`request
`
`Server
`
`Open
`Connection
`
`Send 1st
`request
`
`Receive 1st
`response
`Send 2nd
`request
`
`Receive 2nd
`response
`... etc...
`
`Client
`
`Read
`request
`Send
`response
`
`Read
`request
`Send
`response
`
`Server
`
`Close
`connection
`b) HTTP with persistent connections. A connection is reused for
`performing several requests in a row.
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 14
`
`

`

`50
`
`Web Proxy Servers
`
`Multiple Simultaneous Connections
`[8), open up severalcon:
`Many Web clients, such as Netscape Navigator
`text
`(HTML) and its
`nections simultancously, so that
`the
`document
`inlined images can be loaded simultaneously to improve the (perceive)
`response time (Figure 4.2). The speed improvement
`is caused by tworea-
`sons. First, the retrieval
`for the images in the document can startbefore
`the entire HTML Ále has been loaded, Multiple images can berendered
`simultaneously, instead of having to wait
`for the previous one to finish
`before starting the next one. Second,
`TCP/IP
`tends to give better
`throughput with multiple connections--although such connection hog
`ging" might be considered rude.
`
`Open
`connection#1
`Send
`request #1
`
`Receive
`response #1
`Open more
`connections
`
`Read
`request
`Send
`response
`
`Send more
`requests
`
`Client
`
`Read
`requests
`Send
`responses
`Multiplesimultaneousconnections to increase speed and provide better
`perceived performance.
`
`Server
`
`Figure 4.2
`
`Images in the current document view receive priority. They are laid
`out first, andimages that are currently hidden outside the document view
`will be retrieved only after everything in the current view has been
`retrievedandrendered. All of this contributes to the speed perceived by
`the user.
`Multiplexed Sessions
`A widelysuggestedand generally agreed-upon next step is to allow multi-
`plesessionsto be multiplexed (interleaved) over a single connection. This
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 15
`
`

`

`4
`
`The HTTP Protocol
`
`51
`
`(HTTP-Next
`
`new architecture is commonly referred to as HTTP-NG
`Generation), or HTTP/2.0.
`The idea is simple: add a session layer on top of the connection, and
`each one of the sessions is an individual HTTP request-response transac-
`tion. The session layer interleaves the chunks from each session into a sin-
`gle connection (Figure 4.3). At
`the receiving end, chunks are read, and
`based on their session ID they get passed to the handler of that session
`(request). The next section illustrates a session layer protocol by a simple
`example.
`
`Single Connection
`
`Client
`
`Server
`
`Figure 4.3
`
`o
`
`A session layer protocol.
`Simple Session Layer Protocol Example
`Each chunk of data is prefixed with a session identifier (e.g., 2 bytes), and
`the length of the chunk (2 bytes). The actual data within cach chunk
`belongs to the session identified by the session identifier.
`This way multiple HTTP requests and responses can be sent and
`received over a single TCP connection.
`Comparing Multiple Connectionsvs.SinglePersistentConnection
`A single persistent connection is more network friendly. A long-lived con-
`nection
`handling several requests starts to benefit
`from decongestion
`algorithms used in the network layer of the operating system (or the TCP
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 16
`
`

`

`52
`
`Web Proxy Servers
`
`connection for cachequest
`stack). On the other hand, a single one-shot
`doesn't benefit from them, because by the time the algorithms start tofig-
`ure out the state of the network (whether it's fast or congested), thecon-
`nection is already torn down.
`connections yielda
`simultaneous
`However, by comparison, mulciple
`much beter perceived speed than a single persistent connection (igure
`4.4). This is obvious, because each single transfer must complete before
`the next one can start in the persistent connection scenario.
`
`Multiple Connections
`
`Client
`
`Req
`Req 2
`Req3
`Req 4
`
`T
`Server
`
`Resp 1
`
`>Resp 2
`>Resp 3
`Resp 4
`
`Server
`Client
`One Persistent Connection
`
`Req
`
`Req 2
`
`Req3
`
`Req 4
`
`Resp 1
`
`>Resp 2
`
`>Resp 3
`
`>Resp 4
`
`Figure 4.4
`
`Comparison between multiple simultaneous connections and a single
`persistent connection.
`is, havingseveral persistent connections-
`Combining the two-that
`works somewhat better, as you get the best of both worlds (Figure 4.5).
`However, the benefit ofpersistent connections is reduced by the fact that
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 17
`
`

`

`4
`
`The HTTP Protocol
`
`53
`
`there will be fewer requests made over each persistent connection (since
`there are more connections among which the requests are divided).
`
`Open 2
`connections
`
`Send req 1
`
`Send req 2
`Sendreq3
`Send req 4
`
`Client
`
`Server
`
`Two simultaneous persistent connections.
`HTTP/1.1 Request Pipelining
`To further reduce the latency, request pipelining was added to the
`HTTP/1.1 protocol
`to be used with persistent connections. Pipelining
`means that
`the next request is sent over the persistent connection before
`the previous response has been entirely (or at all)
`received. Figure 4.6
`illustrates pipelining.103
`Open
`connection
`Send several
`requests
`Response1
`Response2 A
`Response3A
`
`Server
`
`Client
`
`Figure 4.5
`
`ei
`
`Response4
`HTTP/1.1 request pipelining with persistent connections.
`
`Figure4.6
`
`Persistent connections and request pipelining have been studied
`extensively, and it has been found that persistent connections alone per-
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 18
`
`

`

`54
`
`Web Proxy Servers
`
`if the next request is sent only after theprcviois
`is,
`form poorly-that
`onefinishes. Pipelining considerably improves performance.
`
`HTTP AUTHENTICATION
`
`authentication mechanisms. One isusedto
`HTTP includes two parallel
`authenticate the user to the final
`destination
`(origin) server. The otheris
`used to authenticate the user to intermediate
`proxy servers. Bothmecha-
`nisms are similar
`in the way they
`function:
`both use a request header,a
`response status code, and a response header. However,
`those statuscodes
`and header names are different based on which type of authentication is
`taking place. Furthermore,
`authentication
`can be performed simulta-
`neously to both intermediate proxy servers, as well as the origin server.
`These two authentication mechanisms
`provide the framework for
`HTTP authentication. Different
`authentication schemes can be imple-
`mented on top of this framework. The HTTP specification definesthe
`"Basic"
`authentication schemne and also mentions
`another one,
`"Digest
`authentication.Thesearediscussed later in this section.
`
`request
`Table4-1 The correspondence between status codes,
`headers, and response headers used by origin server and
`proxy server authentication.
`
`Server authentication
`
`401
`wwW-Authenticate:
`Authorization:
`
`See page
`101
`88
`77
`
`Proxy authentication
`407
`Proxy-Authenticate
`Proxy-Authorization
`
`See page
`101
`88
`78
`
`Regular Server Authentication
`Regular server authentication takes these steps:
`
`1. The origin serverreceives a request without proper authentica-
`tioncredentialsin the
`Authorization:
`header. Itresponds
`with 401 (Auchentication Required) status code, and sends a
`Www-Authenticate:
`header to the client, specifying details
`about how to perform authentication.
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 19
`
`

`

`4 The HTTP Protocol
`
`55
`
`2. The client receives the 401 status code, inspects theWWW-
`Authenticate:
`header, and prompts for the username and
`password from the user.
`3. Client then resends the request, this time with a proper Autho-
`rization:
`headercontaining therequiredauthenticationcre-
`dentials.
`
`Proxy Server Authentication
`Proxy server authentication follows the same framework as regular server
`authentication (challenge-response); however, it uses different status code
`and header names. Table 4-1 shows the correspondence between these
`two authenticationmechanisms.
`Proxy server authentication takes the following steps:
`
`1. Proxy server receives a request without proper proxy authentica-
`tion credentials in the
`Proxy-Authorization:
`header
`field. It responds with the 407 (Proxy Authentication Required)
`statuscode,accompaniedby a
`Proxy-Authenticate:
`response header, specifying details about how to perform proxy
`authentication.
`2. The client receives the 407 status code, inspects the Proxy-
`Authenticate:
`header and prompts for theusername and
`password from the user.
`3. Client
`then resends the request to the proxy, this time with
`proper
`Proxy-Authorization:
`headercontaining the
`required authentication credentials.
`
`Basic HTTP Authentication (to Server)
`The
`“Basic"
`authentication scheme is the only authentication scheme
`defined by the HTTP specification. It does not involve encryption but
`passes
`the
`username
`and
`password
`printable-encodedwhich
`is
`obscured, but effectively in the clear [9]. With HTTP server authentica-
`tion,
`the server will respond with the 401 status code, accompanied by
`the
`Www-Authenticate:
`header, which specifies the authentication
`scheme
`"Basic,"
`and so-called "realm," which is simply a string that
`gets displayed to the user as an indication of who is asking for authentica-
`tion:
`HTTP/1.0 401 Unauthorized
`
`LENNOX EXHIBIT 1014
`Lennox Industries Inc. v. Rosen Technologies LLC, IPR2023-00715, Page 20
`
`

`

`56
`
`Web Proxy Servers
`
`Server: Netscape-Enterprise/3.0
`Date: Sat,
`26 Apr 1997,
`06:03:24 GMT
`WwW-Authenticate: Basic realm="Demo Server"
`The client will prompt
`for the username and password and usebase-64
`printable encoding (RFC 1421) to encode the string with usernameand
`password, separated by a semicolon:
`username:passworprintable_encoded
`Authorization:
`This encoded string will be specified in the
`“Basic':
`header,along with the authentication scheme specifier
`Authorization: Basicus