US007761500B1
`
`US 7,761,500 B1
`(10) Patent No.:
`a2) United States Patent
`Eckertet al.
`(45) Date of Patent:
`Jul. 20, 2010
`
`
`(54) URL BASED COMMUNICATION PROTOCOL
`FROM A CLIENT COMPUTER TO A
`NETWORKDEVICE
`Inventors: Toerless Eckert, Mountain View, CA
`(US); Liming Wei, Fremont, CA (US);
`Dino Farinacci, San Jose, CA (US)
`
`(75)
`
`(73) Assignee: Cisco Technology, Inc., San Jose, CA
`(US)
`
`9/2003 Chenetal. wo... 707/204
`6,625,624 B1*
`
`7,143,439 B2* 11/2006 Cooperetal. ......
`............ 358/1.15
`7,433,070 B2* 10/2008 Koppich et al.
`OTHER PUBLICATIONS
`Reynolds et al. RFC 1700 published by “the Internet Engineering
`Task Force”, pp. 1-56, Oct. 1994."
`* cited by examiner
`
`Primary Examiner—Robert B Harrell
`(74) Attorney, Agent, or Firm—Cesari and McKenna, LLP
`
`(*) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`USC. 154(b)by 0 days.
`(21) Appl. No.: 09/515,941
`
`(22)
`
`Filed:
`
`Feb. 29, 2000
`
`(51)
`
`(56)
`
`ABSTRACT
`(57)
`A methodofsignaling in a computer network uses intercep-
`tion by a network device of a message transmitted by a client
`computer to a server. The message contains a Universal
`Resource Locator (URL), the URL having a reserved port
`designation. The network device parses the URL andinter-
`cepts the message in response to finding the reserved port
`Int. Cl.
`designation in the URL. The network device executes a com-
`(2006.01)
`GO6F 13/00
`mand, where the commandis carriedin a field ofthe inter-
`(52) US. Ch cece 709/203; 709/225; 709/226,
`cepted message. The client computer receives the URL hav-
`709/238: 709/239
`(58) Field of Classification Search 0.0.0.0. "709/203,_ing the reserved port designation in a HTMLfile transmitted
`709/225. 226. 238. 239
`to the client computer bythe server. The message containing
`See applicationfile for complete search history. ;
`the URLis transmitted by the client computer in response to
`a user requesting a resource displayed in a web page dis-
`References Cited
`played by the client computer. A second web pageis trans-
`mitted to the client computer by a server receiving a request
`U.S. PATENT DOCUMENTS
`for services, and the URL containing the port designation is
`written into the second web pageso that the URLis executed
`automatically as the second web page is received by the
`client’ s browser. The methodtransmits a redirect message by
`the network device to the client computer, the redirect mes-
`sage redirecting to an address of a web page without the
`reserved port designation in the URLto carry information to
`the server.
`
`5,636,216 A *
`6/1997 Foxetal. we 370/402
`5,854,901 A * 12/1998 Coleetal. 0... 709/245
`
`5/1999 Danknick et al.
`........... 709/203
`5,901,286 A *
`
`6,006,264 A * 12/1999 Colbyetal. we. 709/226
`
`.........00.. 370/389
`6,055,236 A
`4/2000 Nessett et al.
`
`6,144,996 A * 11/2000 Stamesetal... 709/217
`..........0.0.. 709/227
`6,226,677 B1*
`5/2001 Slemmer
`
`
`5/2001 Sungetal. we. 709/238
`6,226,684 BI*
`........... 709/225
`6,415,323 Bl*
`7/2002 McCanneetal.
`6,449,251 B1*
`9/2002 Awadallah etal.
`.......... 370/229
`
`42 Claims, 10 Drawing Sheets
`
`404B
`
`402
`
`404
`
`406B
`
`L2
`
`u3~—«|:
`
`L4
`<feserved-port>
`
`
`
`
`
`
`
`<PATH> ? <SEARCH PATH>
`
`
`424
`
`OTHER
`FIELDS
`
`GET
`
`Data Co Exhibit 1032
`Data Co Exhibit 1032
`Data Co v. Bright Data
`
`Data Cov. Bright Data
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 1 of 10
`
`US 7,761,500 B1
`
`aéa
`
` g
`
`y=W
`=S
`
`u
`
`— O
`
`o
`re
`
`~~
`
`G3
`
`=
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 2 of 10
`
`US 7,761,500 B1
`
`coe
`
`QN0WYYOMLAN
`
`ONILNANSTdGON
`
`
`
`NOLLNAANISHL
`
`AN3IT9
`
`
`

`

`zeozeBleMEchepleZeAWILAVidsiaVroe"yeoe?41N3!19MYOMLINYYOMLINYaSMONSYasmoudYasn
`
`
`
`
`
`
`
`
`
`
`<W0d-panlasal>YSANaS<WOd-paAsesal>JOVININYYSAYASAd
`
`
`ONINIVLNOOGNY =YaLNAdNOdOLTHNNITWASIML3YLN3I19OL
`
`€“|JOVSSAN=—sSLIWSNVULS3AIZ03Y=SLINSNVYL=SLdSOUSNI
`
`ONINIVLNOOONILVLINIONINIVLNOD=ONINIVLNOO@3y3AN30
`
`
`
`
`
`
`
`SLINSNVYL SQNOdSSY S1d3OUNSLNIYALNdNOD=BDWdSMV~FOUNOSSNLN3MOAG
`
`
`
`
`
`YALNdNOOJOIAaaJOIAIdLNAITONISAAIZOIY=SLSANOIN JOVd4M
`
`
`
`ONYAWOOY3ANSSCNVWIWOOdilHY3LNdWOO
`
`JOVSSAN=YALLNAIWOD‘MSANSS==9oYSANSS=DWSSMJOVSSANJOVSSIN
`
`
`
`
`NOILYOd. JHLSY3HM
`THN4OGNVWWOO
`
`
`
`139=LNANOOLLS3N03ySLINSNVYLFHLWOUWOYSYALNdNOD
`
`
`
`
`WILY3ANSSLNanoLN3I0MYOMLINYYOMLAN
`7goe’zoe”=ZEEoe8ze9z€yee
`
`
`
`CNYWWOSJOSNLVLSONINIVLNODSLdWSLLYONY
`
`
`
`ONINIVLNODJOVSS3WLOFMIGSYLoauIdayLa9
`
`GALVNIDINO=-YSANSSOLSNLVLS ALNOAXSOL
`GbESWILLVLN3I19OLGNYWINOD
`
`
`
`
`SSAIZOSYYALNdWOOYALNdWOOJOIASCJOIAIG
`
`
`SNLVLS—ONINIVLNOOJOVSSINJOVSSANJOVSSAW
`
`
`V])7777[
`
`Jul. 20, 2010
`
`Sheet 3 of 10
`
`US 7,761,500 B1
`
`U.S. Patent
`
`00€
`
`YALNdNOD
`
`
`
`<WOd-peAlasal>SHL
`
`YOLVOIGNI
`
`OLSONSYSIIYVSNIVLNOO
`
`
`
`ONINIVLNODTHNV¥
`
`

`

`O1ONVAINODdlil|
`
`JOIAIGHYOMLIN
`
`GNYWINOD
`
`Tan
`
`TanJO
`
`ySila
`
`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 4 of 10
`
`US 7,761,500 B1
`
`EUSAVT|2UsAVI
`
`JONOHLYOd
`
`NOILYOdSSauaav
`<}J0d-panjesol>
`Y3qvSH|Ys0VSH
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 5 of 10
`
`US 7,761,500 B1
`
`dol Ver
`
`<yod-panasal>
`
`NOLLOANNOD
`
`df-L3$
`
`
`
`
`
`JVIASOHYOMLANAdG31ds9831NILAXDVdJOVSSSWLSINOSZH
`
`
`
`
`
`VySis
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 6 of 10
`
`US 7,761,500 B1
`
`ber
`
`YSHLO
`
`saris
`
`ccy
`
`gv0r
`
`<H1VdHOYVAS>¢<HLVd>
`
`avSls=Ocb
`<piod-paniesau>
` pepe
`v0bCOP
`
`9907
`
`#1
`
`
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 7 of 10
`
`US 7,761,500 B1
`
`1u0d
`
`AYUNLONYLS
`
`VLVG SNOLLONYLSNI
`
`a
`
`
`
`SLINDYIDMYOMLAIN
`
`
`
`"ONIDGIYG‘DNILNOY‘LNdLNO“LNNI
`
`
`
`
`
`GSOld
`
`
`
`12"ONIHOJIMS‘ONILNOY‘ONIDGAHUM3OIAa0NYOMLAN
`
`
`
`
`
`91S0fsPIS
`
`nny2zawi~7yy4S
`
`
`
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 8 of 10
`
`US 7,761,500 B1
`
`
`
`209YYOMLAN
`
`JOVAYSLNI
`
`9Old
`
`ONIOOLNO
`
`SLAWOVd
`
`ONIWOONI
`
`SLaNOVd
`
`LayoVd
`
`NOILWOISISSV19
`
`LINN
`
`cc9
`
`oS
`co
`
`JYVMCYVH
`
`LINA
`
`V9L9
`
`a1avl
`
`F1aVL
`
`a1avl
`
`ONILNOY/ONIHOLIMS
`
`¥rlO\\YZL9cho
`dnoote1|v9
`dN00121
`dNO0171
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 9 of 10
`
`US 7,761,500 B1
`
`700
`
`
`
`610
`
`SEMICONOUCTOR
`CHIP
`
`
`
`FIG. 7
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 10 of 10
`
`US 7,761,500 B1
`
`800
`
`614A 616A
`
`622A 620A YO UNIT
`
`

`

`US 7,761,500 B1
`
`1
`URL BASED COMMUNICATION PROTOCOL
`FROM A CLIENT COMPUTER TOA
`NETWORK DEVICE
`
`FIELD OF THE INVENTION
`
`This invention relates to transmission of messages by a
`client computer connected to a computer network through a
`network device, and more particularly to communication
`from the client computer to the network device, and from a
`server to the network device.
`
`BACKGROUND
`
`The World Wide Web (WWW)is a set of tools and con-
`structs which simplify communication betweena user, using
`aclient computer, and a server holding information which the
`user wishes to receive. The user’s client computer and the
`server computer are linked together by a computer network.
`The user’s client computer runs a computer program called a
`“browser’’,files stored on the server are written in Hypertext
`Markup Language (HTML)sothat the browser will interpret
`the file after it is transferred to the client computer, and
`display thefile as a “Web Page”. The address ofthe Web Page
`is presented to the browser in Universal Resource Locator
`format or (URL), andthe browserinterprets this address to set
`up a communications session from the client to the server to
`transmit a request to the server, and the server reads the URL
`fromthe request in order to transmit a response to the client.
`The protocol used by the browserand the server application is
`referred to as the Hypertext Transfer Protocol (HTTP. The
`communicationssessionis usually set up as a TCP/IP session,
`howeverany reliable packet transfer protocol may be used to
`communicate between a browser running on a client com-
`puter, and a server.
`The following Requests for Comments (RFC) published
`by the Internet Engineering Task ForceETF) describevari-
`ous aspects of the WWWconstructs: RFC 1945, “Hypertext
`Transfer Protocol—HTTP/1.0”; RFC 1630 “Universal
`Resource Identifiers
`in WWW”; RFC 1738 “Uniform
`Resource Locators (URL)’; RFC 1808 “Relative Uniform
`Resource Locators”; all disclosures ofwhich are incorporated
`herein by reference. The Hyper Text Markup Language
`(HTML)is described in the book by Tim Evans, 10 Minute
`Guide to HTML 3.2, Second Edition, published by Que, a
`Division of Macmillan Computer Publishing, New York,
`Copyright date of 1996,all disclosures of which are incorpo-
`rated herein by reference.
`Network devices such as bridges (layer 2 devices), routers
`(layer 3 devices), layer four switches, etc. make up the com-
`puter network connecting the client computer to the server.
`For example, the client computer may be a desktop computer
`located in New York City, and the server computer may be
`located in California. A computer network, for example the
`Internet, may be used to couple the client computer with the
`server. A large number of network devices may be in a chain
`which forwards a packet from theclientto the server, different
`packets may follow different chains of network devices, and
`return packets from the server to the client may follow a
`different chain ofnetwork devices. In anycase, the client will
`usually be connected to a first network device, usually a
`router, and all packets to or from the client will pass through
`this first network device.
`
`It is desirable to directly address a network device during
`the course of exchange of packets during a World Wide Web
`(WWW)communications session. For example, it would be
`convenientfor a client to specify a class of service, fora client
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`to specify a source of a multicast group, for a clientto specify
`apriority fora session, etc. by communicating with a network
`device. However, all of the WWWprotocols ignore network
`devices, and simply transmit packets using a routable proto-
`col. That is, the network devices are transparent to a WWW
`communications session between a client computer and a
`server.
`
`There is needed a simple protocolfor a client computer and
`a server computer to communicate with a network device
`during a WWW communicationssession.
`
`SUMMARYOF THE INVENTION
`
`A method of signaling in a computer network uses inter-
`ception by a network device of a message transmitted by a
`client computer to a server. The message contains a Universal
`Resource Locator (URL), the URL having a reserved port
`designation. The network device parses the URL andinter-
`cepts the message in response to finding the reserved port
`designation in the URL. The network device executes a com-
`mand, where the commandis carried in a field of the inter-
`cepted message. The client computer receives the URL hav-
`ing the reserved port designation ina HTMLfile transmitted
`to the client computer bythe server. The message containing
`the URLis transmitted by the client computer in response to
`a user requesting a resource displayed in a web page dis-
`played by the client computer. A second web pageis trans-
`mitted to the client computer by a server receiving a request
`for services, and the URL containing the port designationis
`written into the second web pageso that the URLis executed
`automatically as the second web page is received by the
`client’ s browser. The methodtransmits a redirect message by
`the network device to the client computer, the redirect mes-
`sage redirecting to an address of a web page without the
`reserved port designation in the URLto carry information to
`the server. The network device may be any convenientnet-
`work device such as a router, a switch, a layer 4 switch,etc.
`Efficient implementation of the invention requires use of a
`field for signaling the network device, where the field is
`parsed by a high speed unit within the network device. An
`implementation ofthe invention uses a “port”field in the URL
`to signal the network device, and so the packet transfer pro-
`tocol must include a “port” field for this implementation of
`the invention, as does the TCP/IP protocol for Hyper Text
`Transfer Protocol. Also, efficient
`implementation of the
`invention requires that the network device parse the URL, as
`do modern layer 4 switches and routers. Uses ofthe invention
`include establishing a multicast group forwarding only pack-
`ets transmitted by a designated source computer, establishing
`a designated quality of service for a communicationssession,
`and other uses of a client computer commanding a network
`device to take action.
`
`Other and further aspects of the present invention will
`become apparent during the course of the following descrip-
`tion and by reference to the accompanying drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Referring now to the drawings, in which like numerals
`represent like parts in the several views:
`FIG. 1 is a block diagram of a computer network using the
`invention.
`
`FIG.2 is a block diagram of a computer network using the
`invention.
`FIG. 3 is a time line of events in accordance with the
`invention.
`
`FIG.4 is a bock diagram ofa typical data packet.
`
`

`

`US 7,761,500 B1
`
`3
`4
`FIG.4A is a field diagram of a REQUEST message.
`<URL:ftp://host.com/> has no user name, while <URL:ftp://
`
`FIG.4B isafield diagram of a GET message. foo:@host.com/> has a user name of “foo” and an empty
`FIG.5 is a block diagram of a network device.
`password.
`host
`FIG.6 is a logic diagram of a network device.
`FIG. 7 is a block diagram of a packet classification unit
`implemented by a semiconductoris chip.
`FIG. 8 is a block diagram of a packet classification unit
`implemented by a local CPU.
`
`DETAILED DESCRIPTION
`
`World Wide Web Features
`Somefeatures ofthe standards used in the World Wide Web
`(WWW)arefirst described. The description is taken from
`RFC 1738 and RFC 1945, both published by the Internet
`Engineering Task Force at the URL www.ietf.org. The fol-
`lowing descriptions of URLsis taken from RFC 1738.
`URL
`
`In general, URLsare written as follows:
`<scheme>:<scheme-specific-part>
`A URL contains the name of the scheme being used
`(<scheme>) followed by a colon and then a string (the
`<scheme-specific-part>) whoseinterpretation depends on the
`scheme.
`
`The characters“3”, “/””, “2”, “, “@”, “=” and “&”are the
`characters which maybereserved for special meaning within
`a scheme.
`
`10
`
`15
`
`20
`
`25
`
`The mapping for some existing standard and experimental
`protocols is outlined. The schemes coveredare:
`
`30
`
`ftp
`http
`gopher
`mailto
`news
`nntp
`telnet
`wais
`file
`prospero
`
`File Transfer protocol
`Hypertext Transfer Protocol
`The Gopherprotocol
`Electronic mail address
`USENETnews
`USENETnewsusing NNTPaccess
`Reference to interactive sessions
`Wide Area Information Servers
`Host-specific file names
`Prospero Directory Service
`
`While the syntax for the rest of the URL mayvary depend-
`ing on the particular scheme selected, URL schemes that
`involve the direct use of an IP-based protocolto a specified
`host on the Internet use a common syntax for the scheme-
`specific data:
`//<user>:<password>@<host>:<port>/<url-path>
`Someorall of the parts “<user>:<password>@”’,“:<pass-
`word>”, “:<port>”, and “/<url-path>” may be excluded. The
`schemespecific data start with a double slash “//” to indicate
`that it complies with the common Internet scheme syntax.
`The different components obey the following rules:
`user
`
`An optional user name. Some schemes(e.g., ftp) allow the
`specification of a user name.
`password
`An optional password.If present, it follows the user name
`separated from it by a colon.
`The user name(and password), if present, are followed by
`a commercial at-sign “@”. Within the user and password
`field, any “:”, “@”, or “T’ must be encoded.
`Note that an emptyuser nameor passwordis different than
`no user name or password; there is no way to specify a
`password without specifying a user name. E.g., <URL:
`ftp://@ host.com/> has an empty user name and no password,
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Thefully qualified domain nameof a networkhost,or its IP
`address as a set of four decimaldigit groups separated by “.”.
`Fully qualified domain names take the form as described in
`Section 3.5 of RFC 1034 and Section 2.1 of RFC 1123: a
`sequence of domain labels separated by “”, each domain
`label starting and ending with an alphanumerical character
`and possibly also containing “-” characters. The rightmost
`domain label will never start with a digit, though, which
`syntactically distinguishes all domain names from the IP
`addresses.
`port
`The port number to connect to. Most schemes designate
`protocols that have a default port number. Another port num-
`ber may optionally be supplied, in decimal, separated from
`the host by a colon. If the port is omitted, the colon is as well.
`url-path
`The rest of the locator consists of data specific to the
`scheme, and is known asthe “url-path”. It supplies the details
`ofhow the specified resource can be accessed. Note thatis the
`“/between the host(orport) and the url-path is NOT part of
`the url-path.
`The url-path syntax depends on the schemebeing used,as
`does the mannerin whichit is interpreted.
`The FTP URL schemeis used to designate files and direc-
`tories on Internet hosts accessible using the FTP protocol
`(RFC 959).
`AFTP URLfollow the syntax described in Section 3.1. If
`:<port> is omitted, the port defaults to 21.
`A user name and password maybe supplied; they are used
`in the ftp “USER”and “PASS” commands afterfirst making
`the connection to the "TP server. Ifno user nameor password
`is supplied and one is requested by the FTP server, the con-
`ventions for “anonymous”FTPare to be used, as follows:
`The user name “anonymous”is supplied.
`The passwordis supplied as the Internet e-mail address of
`the end user accessing the resource.
`If the URL supplies a user name but no password, and the
`remote server requests a password, the program interpreting
`the FTP URL should request one from the user.
`HTTP
`
`The HTTP URL scheme is used to designate Internet
`resources accessible using HTTP (HyperText Transfer Pro-
`tocol).
`An HTTP URLtakes the form:
`
`http://<host>:<port>/<path>?<searchpart>
`
`where <host> and <port> are as described in Section 3.1. If:
`<port> is omitted, the port defaults to 80. No user name or
`password is allowed. <path> is an HTTP selector, and
`<searchpart> is a query string. The <path> is optional, asis
`the <searchpart> andits preceding “?”. If neither <path> nor
`<searchpart> is present, the “/”’ may also be omitted.
`x
`33
`ceprr 669?
`Within the <path> and <searchpart> components,
`“?”are reserved. The “/” character may be used within HTTP
`to designate a hierarchical structure.
`
`Gopher
`The Gopher URL scheme is used to designate Internet
`resources accessible using the Gopherprotocol.
`The base Gopher protocol is described in RFC 1436 and
`supports items and collections of items (directories). The
`Gopher+ protocolis a set ofupward compatible extensions to
`the base Gopherprotocol and is described in. Gopher+ sup-
`
`

`

`US 7,761,500 B1
`
`5
`ports associating arbitrary sets of attributes and alternate data
`representations with Gopheritems.
`Gopher URLs accommodate both Gopher and Gopher+
`items anditem attributes.
`
`Gopher URL Syntax
`A Gopher URLtakes the form:
`gopher://<host>:<port>/<gopher-path>
`
`where <gopher-path> is oneof:
`<gophertype><selector>
`<gophertype><selector>%09<search>
`<gophertype><selector>%09<search>%09<gopher+_
`string>
`If :<port> is omitted, the port defaults to 70. <gophertype>
`is a single-character field to denote the Gopher type of the
`resource to which the URLrefers. The entire <gopher-path>
`may also be empty, in which case the delimiting “/” is also
`optional and the <gophertype> defaults to “1”.
`
`<selector> is the Gopherselector string. In the Gopher pro-
`tocol, Gopherselector strings are a sequence of octets which
`may contain any octets except 09 hexadecimal (US-ASCII
`HT or tab) OA hexadecimal (US-ASCII character LF), and
`OD (US-ASCIcharacter CR).
`Gopherclients specify which item to retrieve by sending
`the Gopherselector string to a Gopherserver.
`Within the <gopher-path>, no characters are reserved.
`Note that some Gopher <selector> strings begin with a copy
`of the <gophertype> character, in which case that character
`will occur twice consecutively. The Gopherselector string
`may be an empty string; this is how Gopherclients refer to the
`top-level directory on a Gopherserver.
`
`Specifying URLs for Gopher Search Engines
`If the URL refers to a search to be submitted to a Gopher
`search engine, the selector is followed by an encoded tab
`(%09) and the search string. To submit a search to a Gopher
`search engine, the Gopherclient sends the <selector> string
`(after decoding), a tab, and the search string to the Gopher
`server.
`
`mailto URL takes the form:
`
`mailto:<rfc822-addr-spec>
`
`where <rfc822-addr-spec> is (the encoding of an) addr-spec,
`as specified in RFC 822.
`News
`The news URL schemeis used to refer to either news
`
`groupsor individualarticles ofUSENET news, as specified in
`RFC 1036.
`A news URLtakes one of two forms:
`
`news:<newsgroup-name>
`news:<message-id>
`A <newsgroup-name> is a period-delimited hierarchical
`name, such as to “comp.infosystems.www.misc”. A <mes-
`sage-id> corresponds to the Message-ID of section 2.1.5 of
`RFC 1036, without the enclosing “<” and “>”; it takes the
`form <unique>@<full_domain_name>. A messageidentifier
`may be distinguished from a news group name by the pres-
`ence ofthe commercialat “@”character. No additional char-
`acters are reserved within the components of a news URL.
`If <newsgroup-name> is “*” (as in <URL:news:*>), it is
`usedto refer to “all available news groups”.
`The news URLsare unusualin that by themselves, they do
`not contain sufficient information to locate a single resource,
`but, rather, are location-independent.
`
`NNTP
`
`6
`
`The nntp URL schemeis an alternative method ofrefer-
`encing newsarticles, useful for specifying newsarticles from
`NNTPservers (RFC 977).
`A nntp URLtake the form:
`nntp://<host>:<port>/<newsgroup-name>/<article-num-
`ber>
`
`10
`
`where <host> and <port> are as described in RFC 1945
`Section 3.1. If :<port> is omitted, the port defaults to 119.
`The <newsgroup-name> is the name of the group, while
`the <article-number> is the numeric id ofthe article within
`
`that newsgroup.
`Telnet
`
`The Telnet URL schemeis used to designate interactive
`services that may be accessed by the Telnet protocol.
`A telnet URLtakes the form:
`
`telnet://<user>:<password>@<host>:<port>/
`
`and, the final “/” character may be omitted.
`If :<port> is omitted, the port defaults to 23. The :<pass-
`word> can be omitted, as well as the whole <user>:<pass-
`word> part.
`The telenet URL doesnot designate a data object, but rather
`an interactive service. Remote interactive services vary
`widely in the means by which they allow remote logins; in
`practice, the <user> and <password> supplied are advisory
`only: clients accessing a telnet URL merely advise the user of
`the suggested username and password.
`HTTP
`
`The Hypertext Transfer Protocol (HTTP) is described in
`RFC 1945. The following description is taken, substantially
`verbatim from RFC 1945. Also, additional details of HTTP
`are given in RFC 1945.
`The Hypertext Transfer Protocol (HTTP) 1s an application-
`level protocol with the lightness and speed necessary for
`distributed, collaborative, hypermedia information systems.
`HTTPis also used as a generic protocol for communication
`between user agents and proxies/gateways to other Internet
`protocols, such as SMTP, NNTP, FTP, Gopher, and WAIS,
`allowing basic hypermedia access to resources available from
`diverse applications and simplifying the implementation of
`user agents.
`
`Terminology
`This specification uses a number oftermsto refer to the
`roles played by participants in, and objects of, the HTTP
`communication.
`
`20
`
`25
`
`40
`
`45
`
`Connection
`
`50
`
`A transport layer virtual circuit established between two
`application programs for the purpose of communication.
`
`Message
`The basic unit of HTTP communication, consisting of a
`structured sequenceof octets matching the syntax defined in
`RFC 1945 Section 4 and transmitted via the connection.
`
`Request
`An HTTP request message (as defined in RFC 1945 Sec-
`tion 5).
`
`Response
`An HTTPresponse message(as defined in RFC 1945 Sec-
`tion 6).
`Resource
`
`A network data object or service which can be identified by
`a URI or URL (RFC 1945 Section 3.2).
`
`

`

`US 7,761,500 B1
`
`7
`
`8
`
`Entity
`A particular representation or rendition of a data resource,
`or reply from a service resource, that may be enclosed within
`a request or response message. An entity consists of meta-
`information in the form of entity headers and content in the
`form of an entity body.
`Client
`
`An application program that establishes connections for
`the purpose of sending requests.
`
`10
`
`User Agent
`The client whichinitiates a request. These are often brows-
`ers, editors, spiders (web-traversing robots), or other end user
`tools.
`
`Server
`
`An application program that accepts connections in order
`to service requests by sending back responses.
`
`Origin Server
`The server on which a given resource resides or is to be
`created.
`
`Proxy
`An intermediary program which acts as both a server anda
`client for the purpose of making requests on behalf of other
`clients. Requests are serviced internally or by passing them,
`with possible translation, on to other servers. A proxy must
`interpret and, if necessary, rewrite a request message before
`forwarding it. Proxies are often used as client-side portals
`through networkfirewalls and as helper applications for han-
`dling requests via protocols not implemented by the user
`agent.
`
`Gateway
`A server which acts as an intermediary for some other
`server. Unlike a proxy, a gateway receives requests as if it
`were the origin server for the requested resource; the request-
`ing client may not be aware that it is communicating with a
`gateway. Gateways are often used as server-side portals
`through network firewalls and as protocol translators for
`access to resources stored on non-HTTP systems.
`Tunnel
`
`A tunnel is an intermediary program whichis acting as a
`blind relay between two connections. Onceactive, a tunnelis
`not considered a party to the HTTP communication, though
`the tunnel may have beeninitiated by an HTTP request. The
`tunnel ceases to exist when both endsof the relayed connec-
`tions are closed. Tunnels are used when a portal is necessary
`and the intermediary cannot, or should not,
`interpret the
`relayed communication.
`Cache
`
`A program’s local store of response messages and the
`subsystem that controls its message storage, retrieval, and
`deletion. A cache stores cacheable responses in order to
`reduce the response time and network bandwidth consump-
`tion on future, equivalent requests. Any client or server may
`include a cache, though a cache cannot be used bya server
`while it is acting as a tunnel.
`Any given program maybe capable of being both a client
`and a server; our use of these termsrefers only to the role
`being performed by the program for a particular connection,
`rather thanto the program’s capabilities in general. Likewise,
`any server may act as an origin server, proxy, gateway, or
`tunnel, switching behavior based on the nature of each
`request.
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Overall Operation
`The HTTPprotocol is based on a request/response para-
`digm. A client establishes a connection with a server and
`sends a request to the server in the form of a request method,
`URI, and protocol version, followed by a MIME-like mes-
`sage containing request modifiers, client information, and
`possible body content. The server responds witha status line,
`including the message’s protocol version and a success or
`error code, followed by a MIME-like message containing
`server information, entity meta-information, and possible
`body content.
`Most HTTP communicationis initiated by a user agent and
`consists ofa request to be applied to a resource on someorigin
`server. In the simplest case, this may be accomplishedvia a
`single connection (v) between the user agent (UA) and the
`origin server (O).
`
`request chain ------------>
`UArr rrr rrreeocrsscccsss oO
`os response chain
`
`A more complicated situation occurs when one or more
`intermediaries are present
`in the request/response chain.
`There are three commonformsof intermediary: proxy, gate-
`way, and tunnel. A proxy is a forwarding agent, receiving
`requests for a URI in its absolute form, rewritingall or parts
`of the message, and forwarding the reformatted request
`towardthe serveridentified by the URI. A gatewayis a receiv-
`ing agent, acting as a layer above someotherserver(s) and,if
`necessary, translating the requests to the underlying server’s
`protocol. A tunnelacts as a relay point between two connec-
`tions without changing the messages; tunnels are used when
`the communication needs to pass through an intermediary
`(suchasa firewall) even whenthe intermediary cannot under-
`stand the contents of the messages.
`
`request chain --------------->
`UA>+ ver Arn -B eve --G--v---O
`ote eee eee response chain
`
`Thefigure above showsthree intermediaries (A, B, and C)
`between the user agent and origin server. A request or
`response message that travels the whole chain must pass
`through four separate connections. This distinction is impor-
`tant because some HTTP communication options may apply
`only to the connection with the nearest, non-tunnel neighbor,
`only to the end-points ofthe chain, or to all connections along
`the chain. Although the diagram is linear, each participant
`maybe engaged in multiple, simultaneous communications.
`For example, B maybereceiving requests from manyclients
`other than A, and/or forwarding requeststo servers other than
`C, at the same timethat it is handling A’s request.
`Anyparty to the communication which is not acting as a
`tunnel may employ an internal cache for handling requests.
`The effect of a cache is that the request/response chain is
`shortened if one of the participants along the chain has a
`cached response applicable to that request. The following
`illustrates the resulting chain if B has a cached copy of an
`earlier response from O (via C) for a request which has not
`been cached by UA or A.
`
`

`

`US 7,761,500 B1
`
`request chain ---->
`UAr reve r-Ae--w--B----C----0
`Koren n--response chain
`
`Not all responses are cacheable, and some requests may
`contain modifiers which place special requirements on cache
`behavior. Some HTTP/1.0 applications use heuristics to
`describe whatis or is not a “cacheable” response, but these
`rules are not standardized.
`
`On the Internet, HTTP communication generally takes
`place over TCP/IP connections. The default port is TCP 80,
`but other ports can be used. This does not preclude HTTP
`from being implemented on top of any other protocol on the
`Internet, or on other networks. HTTP only presumesa reliable
`transport; any protocol that provides such guarantees can be
`used, and the mapping of the HTTP/1.0 request and response
`structures onto the transport data units of the protocol in
`question is outside the scopeofthis specification.
`Except for experimental applications, current practice
`requires that the connectionbe established by the client prior
`to each request and closed by the server after sending the
`response. Both clients and servers should be awarethat either
`party may close the connection prematurely, due to user
`action, automated time-out, or program failure, and should
`handle such closing in a predictable fashion. In any case, the
`closing of the connection by either or both parties always
`terminates the current request, regardless of its status.
`Uniform Resource Identifiers
`
`URIs have been known by many names: WWWaddresses,
`Universal Document Identifiers, Universal Resource Identi-
`fiers, and finally the combination ofUniform Resource Loca-
`tors (URL) and Names (URN). Asfar as HTTPis concerned,
`Uniform Resource Identifiers are simply formatted strings
`which identify—via name,location, or any other character-
`istic—a network resource.
`
`URIs in HTTP can be represented in absolute form or
`relative to some known base URI, depending uponthe context
`of their use. The two formsare differentiated by the fact that
`absolute URIs always begin with a scheme namefollowed by
`a colon.
`
`URI=(absoluteURIIrelativeURI)[“#” fragment]
`absoluteURI=scheme“:”’*(ucharlreserved)
`relativeURI=net_pathlabs_pathlrel_path
`HTTP URL
`
`The “http” schemeis used to locate network resources via
`the HTTPprotocol. This section defines the scheme-specific
`syntax and semantics for http URLs.
`http_URL=“http:”“//” host[:” port] [abs_path]
`host=<A legal Internet host domain nameor IP address (in
`dotted-decimal form), as defined by Section 2.1 of RFC
`1123>
`
`port="DIGIT
`If the port is empty or not given, port 80 is assumed. The
`semantics are that the identified resource is located at the
`
`serverlistening for 'l’}CP connections on that port of that host,
`and the Request-URI for the resource is abs_path. If the
`abs_path is not present in the URL, it must be given as “/”
`when used as a Request-URI (RFC 1945 Section 5.1.2).
`Note: Although the HTTP protocol is independent of the
`transport
`layer protocol,
`the http URL only identifies
`resources by their TCP location, and thus non-TCP resources
`must be identified by some other URI scheme.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`