Method and apparatus for providing increased content from a resource constrained device

The invention relates to electronic networks. More particularly, the invention relates to a method and apparatus for providing increased content from a resource constrained device.

With the explosive growth of the Internet, computer users and network administrators are requiring that they be able to access and administer systems via a World Wide Web (Web) browser. The graphical interfaces to which users have become accustomed require large amounts of data storage. Systems that have large amounts of disk storage are able to present this information directly to the user.

Embedded systems, such as printers and other peripheral devices, typically have less data storage capacity. This lack of capacity limits the content that such embedded devices can provide directly to a user. As a result of this lack of storage capacity, such embedded devices must present a less elegant, non-intuitive interface to a user, <i>e.g.</i> an interface that is presented textually with few graphical images. This may cause confusion to the user as to how to access information on the device and how to configure the device.

It would be advantageous to provide a technique that allows a resource constrained embedded device to offer greater content to a user when the device is accessed, for example, where the device supports a commonly accepted Web browser metaphor.

Document "Scalable Web Server architectures" published in proceedings of the second IEEE Synposium as computers and communication 1-3 July 1997 pages 12-16 (ISBN 0-8186-7852-6) discloses a web server architecture in which a hierarchy is implemented. Data is partitioned according to content and stored in different HTTP servers. Redirection servers distribute user's requests to the relevant HTTP server.

Document "HTTP, Java provide run-time control" published in Electronic Engineering Times No. 926, November 1996 (XP00 2075445) discloses that Java can be used to connect an embedded device to the Internet for access and control.

Document WO 96/42041 discloses a method for controlling and monitoring access to network servers. A client views a document within a browser. The document is in hypertext format and includes links to other hypertext pages. Upon selection of a link, a server submits the request to a secondary server that validates access for the client.

Document "Java goes to work controlling network embedded systems" published in Computer Design Vol. 35, No. 9, August 1996 page 36-37 (XP 000631206) discloses a software module that can interface with another program and permits access to the program via a web browser over the Internet.

According to an aspect of the present invention there is provided an apparatus for allowing resource constrained devices to present more content as specified in claim 1.

The preferred embodiment provides an HTTP redirector that solves the problem of providing a sophisticated graphical user interface for resource constrained embedded devices by allowing such devices to present more content to the end user without storing the data locally. This data is provided by the use of a content server, as well as the content server's resources, to present the information to the user. The redirect scheme herein allows the bulk of the embedded device specific content (e.g. HTML and/or JAVA applet files) to reside on a content server, rather than on the peripheral device itself.

The preferred embodiment also allows JAVA applets, located on a content server, to be used to implement peripheral specific content and pages. The JAVA language is attractive for such application because it provides a more powerful programming environment than HTML for constructing interactive user interface programs and for refreshing status displays. Using the content server's resources therefore allows the resource constrained device to present richer content to the user. Further, by using the herein disclosed redirector, a device may readily present JAVA applets that require more memory than locally available, thus resulting in substantial resource leverage.

The preferred embodiment can provide functionality that supports a Web-based peripheral management solution based upon JAVA applets and a top-level user interface (U) generator located on a content server. In the herein disclosed scheme, hyper text transfer protocol (HTTP) daemons (i.e. Web servers) run on both a peripheral device interface and a host machine content server. Web browser accesses to the peripheral device HTTP daemon for peripheral or other content are redirected by the peripheral device HTTP daemon to a content server where the actual hyper text markup language (HTML) or JAVA applet files are stored. The peripheral device interface also generates HTML stub files to aid in redirecting accesses to JAVA applets on the content server.

According to another aspect of the present invention, there is provided a method in Claim 10.

Preferably, the browser follows the links to the peripheral interface and device pages by getting addresses for peripheral interface and device specific pages.

Advantageously, the peripheral interface and device specific pages are implemented as applet and class files that are stored on the content server, wherein the applet and class files load and execute in the browser, and wherein the applet and class files communicate with the peripheral interface and thereby the device.

The browser may contact the peripheral interface, and the peripheral interface may redirect the browser using information page redirection.

In an embodiment, the browser contacts the user interface server at a redirected location that contains the link, the link instructs the user interface server to contact the peripheral interface from a redirect address and to pass data contained at the address to the peripheral interface, causing a page to be sent to the browser from the peripheral interface, the page containing a reference to an applet file.

Preferably, the applet file reference establishes a contact to the peripheral interface at the redirect address, thereby downloading the applet file to enhance the functionality of the peripheral interface.

The browser preferably downloads the applet file from a redirect location on the content server.

The browser may communicate with the peripheral interface to retrieve required information once the applet file has been loaded by the browser.

The interface generator may include a stub file mechanism for triggering an applet file fetch.

In an embodiment, the peripheral interface performs either of token substitution on the body of the stub page allowing inclusion of any of configuration and identity information contained on the peripheral interface, and string processing, including space substitution and escape conversion.

The substitution tokens may include any of a fully qualified domain name and base URL path of a host software location on the system server; an interface fully qualified domain name; an interface MAC address; an interface model identifier string; and a peripheral model identifier string.

The user interface generator may contain information concerning the location of applet files on the content server, the height/width of the applet area, and whether the applet file name should be customized to contain strings for the peripheral interface or device type.

Preferably, the user interface generator is designed to invoke an applet from a user interface page by placing a link in the user interface page that contains the address of a peripheral interface stub generator. The address may also contain a body parameter which is in an entire applet tag to be inserted into the stub page returned by the peripheral interface. The applet tag text may include any tokens that the user interface generator requires the peripheral interface to substitute into the stub page, causing modification of the applet file name or directory path.

In an embodiment, the browser is operable to receive the stub page and processes the applet tag, and then gets an associated applet file. The mechanism may be configured such that the browser must make a get request for applet file addresses to the peripheral interface and have those requests redirected to addresses on the content server.

An applet tag text, which the user interface generator link passes to the peripheral interface stub generator, may be the path to the applet file and the name of the applet file, wherein the path contains an initial redirect component which is returned unaltered in the stub file and which becomes the path used by the browser when getting the applet file.

An embedded daemon on the peripheral interface may perform redirection of any request which contains a specific initial directory path in the request address.

The or an applet may make requests to either of the peripheral interface and the device to perform specific operations once the browser retrieves and starts running the applet. Preferably, the peripheral interface performs redirection of all requests for either of the peripheral interface root or home page addresses, wherein a specific home page address is configured in the peripheral interface, wherein the peripheral interface responds with a status code and a location address that has been preconfigured but that undergoes token substitution when the peripheral interface receives a request for the peripheral interface home page.

An embodiment of the present invention is described below, by way of example only, with reference to the accompanying drawings, in which: <ul id="ul0001" list-style="none"><li>Fig. 1 is a block schematic diagram that presents an embodiment of a Web redirect mechanism;</li><li>Fig. 2 is a block schematic diagram that shows device discovery, top level UI generation, and client browser fetch of a top level UI page according to an embodiment of the invention;</li><li>Fig. 3 is a block schematic diagram that shows a user following a link on a page, a client browser invoking the peripheral interface stub generator and receiving an HTML stub file (e.g. to trigger fetch of Java Applet) according to an embodiment of the invention;</li><li>Fig. 4 is a block schematic diagram that shows a client browser fetching a Java applet with HTTP redirection;</li><li>Fig. 5 is a block schematic diagram that shows a Java applet communicating with a peripheral interface and/or peripherals according to an embodiment of the invention;</li><li>Fig. 6 is a block schematic diagram that shows a client browser accessing a peripheral interface root URL and being redirected to a top level UI generator according to an embodiment of the invention; and</li><li>Fig. 7 is a block schematic diagram that shows a browser accessing a peripheral interface root URL and being redirected to an HTML home page according to an embodiment of the invention.</li></ul>

The preferred embodiment provides an HTTP redirector that solves the problem of providing a sophisticated graphical user interface for resource constrained embedded devices by allowing such devices to present more content to the end user without storing the data locally. This data is provided by the use of a content server, and the content server's resources, to present the information to the user. The redirect scheme herein allows the bulk of the embedded device specific content (<i>e.g.</i> HTML and/or JAVA applet files) to reside on a content server, rather than on the peripheral device itself.

The preferred embodiment also allows JAVA applets, located on a content server, to be used to implement peripheral specific content and pages. The JAVA language is attractive for such application because it provides a more powerful programming environment than HTML for constructing interactive user interface programs and for refreshing status displays. Using the content server's resources therefore allows the resource constrained device to present richer content to the user. Further, by using the herein disclosed redirector, a device may readily present JAVA applets that require more memory than is locally available, thus resulting in substantial resource leverage.

The preferred embodiment operates in an electronic network in conjunction with host software which delivers Web-based management capabilities for peripheral devices. The peripheral devices are directly attached to the network via the novel interfaces (the "interface") set forth herein. The host software may be any generic software that runs on a content server (<i>e.g.</i> as CGI-bin scripts and DLLs) and that presents a top level user interface for peripheral management. Such top level user interface should provide user access to a collection of specific pages for management of the herein described novel interface and associated peripheral (<i>e.g.</i> status, configuration, and jobs).

The preferred embodiment provides Web redirect functionality which supports a Web-based peripheral management solution based upon JAVA applets and a top-level UI generator located on a content server. There are HTTP daemons (<i>i.e.</i> Web servers) in the Web redirect scheme running on both the interface and a host machine content server. Web browser accesses to the interface HTTP daemon for peripheral or interface content are redirected by the interface HTTP daemon to a content server where the actual HTML or JAVA applet files are stored. The interface also generates HTML stub files to aid in redirecting accesses to JAVA applets on the content server.

Fig. 1 is a block schematic diagram that shows the primary system components, which include the following: <ul id="ul0002" list-style="bullet"><li>Client Browser 14;</li><li>Top level Ul Server (TLUI) 12;</li><li>Peripheral 18;</li><li>Peripheral Interface 16; and</li><li>Content Server 10.</li></ul>

Operation of the invention is described below in connection with Figs. 2-7.

Fig. 2 is a block schematic diagram that shows device discovery, top level UI generation, and client browser fetch of a top level UI page. Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 2 by lines 21-24.

Step 1 - Discovery Query (21).

The top level UI server sends out queries on the network to locate the available peripheral interfaces and peripherals. Various discovery and management protocols may be used to discover available devices and retrieve information about each of those devices. Initial queries can be broadcast or multicast to groups of devices for discovery purposes, followed by queries directed to each device to obtain device specific identification information.

Step 2 - Discovery Reply (22).

Each device replies with the requested information to the top level UI server's query or queries.

Step 3 - TLUI Get (23).

The user interacts with the client browser in some manner that causes the client browser to send an HTTP GET to the top level UI (TLUI) server for the URL of the TLUI page (<i>e.g.</i> entering a URL, choosing an item from a Favorites/Bookmark/History list).

Step 4 - TLUI Reply (24).

The top level Ul server receives the GET and invokes the top level Ul generator 13. The top level Ul generator constructs HTML for the TLUI page (it may dynamically generate this HTML). On the TLUI page, there is a peripheral management hypertext link that the user can follow to invoke a peripheral-specific management Java applet. The URL associated with this hypertext link is the URL of the stub generator 15 on the peripheral interface. This URL includes parameters that are passed to the stub generator and which are essentially the text for an APPLET tag that references the peripheral management Java applet. The client browser receives the TLUI page HTML and presents the graphical TLUI page to the user.

Notes.

<ul id="ul0003" list-style="bullet"><li>The TLUI may be more complicated than described, consisting of multiple pages and/or frame areas on the screen.</li><li>The TLUI may be constructed from Java applets rather than HTML pages.</li><li>Management is a general term and could include configuration, status, control, or other types of operations with the peripheral interface or peripheral.</li><li>The peripheral specific management may be more complicated than described above, consisting of multiples HTML pages and/or Java applets.</li></ul>

Fig. 3 is a block schematic diagram that shows a user following a link on a page, a client browser invoking the peripheral interface stub generator and receiving an HTML stub file (<i>e.g.</i> to trigger fetch of Java Applet). Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 3 by lines 31, 32.

Step 1 - StubGen Get (Applet) (31).

When the user follows the peripheral management link on the page, the client browser performs an HTTP GET to the peripheral interface to obtain the URL for the stub-generator, also passing in the URL parameters (<i>e.g.</i> The APPLET tag text).

Step 2 - StubGen Reply (Applet) (32).

The peripheral interface receives the GET and invokes the stub generator. The stub generator constructs a small HTML file (termed a stub file) in which the passed-in URL parameters become the body of the HTML file. In this instance, the URL parameter is the text for an APPLET tag, and the resulting HTML stub file contains an APPLET tag that references the peripheral management Java applet. The APPLET tag indicates that the Java applet is located on the peripheral interface. The HTML stub file is returned to the client browser.

Notes.

<ul id="ul0004" list-style="bullet" compact="compact"><li>String token substitution may be performed on the contents of the stub file before being sent back to the browser.</li></ul>

Fig. 4 is a block schematic diagram that shows a client browser fetching a Java applet with HTTP redirection. Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 4 by lines 41-44.

Step 1 - Applet Get (41).

The client browser receives and processes the HTML stub file. In processing the APPLET tag, the client browser sends an HTTP GET to the peripheral interface, specifying the URL for the Java applet. The URL for the Java applet consists of a special initial directory path component (<i>e.g.</i> /redirect), followed by the relative path to the Java applet.

Step 2 - Applet Reply (Redirect) (42).

The peripheral interface detects the /redirect and invokes the general redirect 17. The general redirect sends a reply back to the client browser indicating an HTTP status of temporarily moved. The location field in the reply is the URL of the Java applet on the content server. The general redirect removes the /redirect component from the URL and substitutes in its place the host name and initial path for the location of the Java applet on the content server. The reply is returned to the client browser.

Step 3 - Applet Get (43).

The client browser receives the reply and processes the reply with the moved temporarily status. The browser sends an HTML GET to the content server for the URL of the Java applet (as received from the peripheral interface general redirect).

Step 4 - Applet Reply (44).

The content server receives the GET, locates the specified Java applet, and returns the Java applet to the client browser. The client browser loads the Java applet into the Java environment and the Java applet starts executing.

Notes.

<ul id="ul0005" list-style="bullet"><li>This assumes that the peripheral interface has been previously configured with the URL path to Java applets on the content server.</li><li>String token substitution may be performed on the redirect URL in the location field of the redirected reply.</li><li>Java class file references also use the same redirection mechanism.</li></ul>

Fig. 5 is a block schematic diagram that shows a Java applet communicating with a peripheral interface and/or peripherals. Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 5 by lines 51, 52.

Step 1 - Mgmt Request (51).

The Java applet sends management requests directly to the peripheral interface and/or peripheral using the appropriate protocols(s) (<i>e.g.</i> SNMP).

Step 2 - Mgmt Reply (52).

The peripheral interface and/or peripheral performs the requested management actions and/or returns the requests management information.

Fig. 6 is a block schematic diagram that shows a client browser accessing a peripheral interface root URL and being redirected to a top level Ul generator. Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 6 by lines 61-64.

Step 1 - Root URL Get (61).

The user interacts with the client browser in a manner that causes the client browser to send an HTTP GET to the peripheral interface for the root URL (/).

Step 2 - Root URL Reply (Redirect) (62).

The peripheral interface receives the GET and invokes the root URL redirect 19. The peripheral interface root URL redirect sends a reply with an HTTP status of moved temporarily, and the redirected URL location. In this instance, the redirected URL location is configured on the peripheral interface as the URL of the top level Ul generator on the top level Ul server. In addition, the redirected URL may include URL parameters that contain peripheral interface and/or peripheral specific information.

Step 3 - Root URL Get (63).

The client browser receives the reply and processes the moved temporarily status. The client browser sends an HTML GET to the top level Ul server for the URL of the top level Ul generator (as received from the peripheral interface root URL redirect including URL parameters).

Step 4 - Root URL Reply (64).

The top level Ul generator constructs a TLUI page to be returned to the client browser. The top level Ul generator may use URL parameters (containing peripheral interface and/or peripheral specific information) to select peripheral interface or peripheral specific page content. The TLUI page is returned to the client browser. The client browser receives the TLUI page HTML and presents the graphical TLUI page to the user.

Notes.

<ul id="ul0006" list-style="bullet"><li>Assumes that the root redirect URL has been configured into the peripheral interface.</li><li>String token substitution may be performed on the root redirect URL.</li></ul>

Fig. 7 is a block schematic diagram that shows a browser accessing a peripheral interface root URL and being redirected to an HTML home page. Operation of this embodiment of the invention involves the following actions, which are identified on Fig. 7 by lines 7-74.

Step 1 - Root URL Get (71).

The user interacts with the client browser in a manner that causes the client browser to send an HTTP GET to the peripheral interface for the root URL (/).

Step 2 - Root URL Reply (Redirect) (72).

The peripheral interface receives the GET and invokes the root URL redirect. The peripheral interface root URL redirect sends a reply with an HTTP status of moved temporarily, and the redirected URL location. In this instance, the redirected URL location is configured on the peripheral interface as the URL of a stand alone HTML home page on the content server.

Step 3 - Root URL Get (73).

The client browser receives the reply and processes the moved temporarily status. The client browser sends an HTML GET to the content server for the URL of the stand alone HTML home page (as received from the peripheral interface root URL redirect).

Step 4 - Root URL Reply (74).

The content server receives the GET, locates the specified HTML page, and returns the HTML page to the client browser. The client browser displays the page to the user. On the stand alone home page there is a hypertext link that the user can follow to invoke a peripheral-specific management Java applet. The URL associated with this item is the URL of the stub generator on the peripheral interface. The URL includes parameters that are passed to the stub generator and which are essentially the text for an APPLET tag that references the peripheral management Java applet.

Notes.

<ul id="ul0007" list-style="bullet"><li>Assumes that the root redirect URL has been configured into the peripheral interface.</li><li>The standalone HTML home page may be more complicated than described, consisting of multiple pages and/or frame areas on the screen.</li><li>String token substitution may be performed on the root redirect URL.</li></ul>

Web redirect.

The basics of the Web redirect scheme are as follows: <ul id="ul0008" list-style="bullet"><li>A top-level Ul generator executes as CGI bin scripts and DLLs on the top-level Ul server with the associated URLs. The top-level Ul generator provides a high level user interface for peripheral management including, for example, discovery and search capabilities, group management, and navigation. The top-level UI generator feeds HTML pages to the browser to present the top-level Ul. These top-level Ul HTML pages include hypertext links to URLs for interface and peripheral specific pages. As the user navigates through the top-level Ul pages they select interface and peripheral specific pages (<i>e.g.</i> printer status and interface configuration) causing the browser to follow links to these pages by performing HTTP GETs of the URLs for the interface and peripheral specific pages.</li><li>The interface and peripheral specific pages are implemented as JAVA applets and classes. They could also be HTML or other files, if desired. These JAVA applet and class files are stored on the content server, load/execute in the browser, and then use SNMP to communicate further with the interface or peripheral.</li><li>To load/execute a JAVA applet, the browser follows a hypertext link from the top-level UI page to a small HTML page containing an HTML APPLET tag, which indicates the URL of the JAVA applet file on the content server. The APPLET tag has various parameters which indicate the name of the JAVA applet file (CODE=), the absolute URL to the JAVA applet file directory (CODEBASE=), and the height and width of the screen area occupied by the applet (HEIGHT=, WIDTH=). An HTML stub file mechanism is used to trigger the JAVA applet file fetch which involves both the interface and top-level Ul generator: <ul id="ul0009" list-style="dash" compact="compact"><li>The interface contains an embedded HTTP daemon (<i>i.e.</i> Web server) which dynamically generates the HTML stub pages that contain the APPLET tags. A specific URL ("/stubgen") on the interface invokes the HTML stub page generator. The interface HTML stub page generator is generic in that it takes a parameter ("body=") following the request URL and uses its value as the body of the HTML page returned to the browser. The interface performs token substitution on the body of the HTML stub page allowing inclusion of configuration/identity information contained on the interface. The substitution tokens include: <ul id="ul0010" list-style="none"><li>The fully qualified domain name and base URL path of the host software's location on the content server;</li><li>The interface fully qualified domain name;</li><li>The interface MAC address;</li><li>The interface model identifier string; and</li><li>The peripheral model identifier string.</li></ul></li><li>The top-level UI generator contains information concerning the location of the JAVA applet files on the content server, the height/width of the applet area, and whether the applet file name should be customized to contain strings for the interface type of peripheral type. To invoke a JAVA applet from a top-level UI page, the top-level Ul generator places a hypertext link in the page which contains the URL of the interface HTML stub generator. The URL also contains a "body=" parameter which is, in fact, the entire APPLET tag text to be inserted into the HTML stub page returned by the interface. In addition, the APPLET tag text includes any tokens which the top-level UI generator requires the interface to substitute into the HTML stub page, causing modification of the JAVA applet file name or directory path. When the user follows the hypertext link to the interface or peripheral specific page, the browser sends an HTTP GET request to the interface specifying the URL of the stub file generator and passing the "body=" parameter in the request URL. The interface returns to the browser a small HTML page containing the "body=" value with substituted tokens.</li></ul></li><li>Once the browser receives the HTML stub page and processes the APPLET tag, it then proceeds to perform an HTTP GET of the JAVA applet file. To work within the JAVA security constraints, the browser must make the HTTP GET requests for JAVA applet/class file URLs to the interface and have those requests redirected to URLs on the content server. An HTTP redirect mechanism is used which involves both the top-level Ul generator and interface. In the APPLET tag text (which the top-level Ul hypertext link passes to the interface HTML stub generator as the body= parameter) is the path to the JAVA applet file (in the CODEBASE= parameter) and the name of the JAVA applet file (in the CODE= parameter). The path specified in the CODEBASE= parameter contains an initial "/redirect" component which is returned unaltered in the HTML stub file and which becomes the path used by the browser when performing an HTTP GET of the JAVA applet file. <ul id="ul0011" list-style="dash" compact="compact"><li>The embedded HTTP daemon (<i>i.e.</i> Web server) on the interface performs redirection of any HTTP request which contains a specific initial directory path ("/redirect") in the request URL. For HTTP requests whose URL contains the redirect directory path, the interface sends back an HTTP response which contains a status code "moved temporarily" and a location URL which is the request URL with the /redirect path stripped off and a pre-configured host software base URL inserted in its place. The interface also performs token substitution on the response location URL if any tokens are present.</li></ul></li><li>Once the browser retrieves and starts running the JAVA applet, the JAVA applet makes SNMP requests to the interface or peripheral to perform specific operations.</li><li>The interface performs redirection of all HTTP requests for its root ("/") or home page URL similar to the general redirect mechanism. A specific home page URL is configured in the interface. When the interface receives an HTTP request for its home page, it sends back an HTTP response with a status code "move temporarily" and a location URL that has been pre-configured but that undergoes token substitution.</li></ul>

Web redirect functions.

The Web redirect mechanism is comprised of the following capabilities embedded in firmware: <ul id="ul0012" list-style="bullet"><li>Configuration Information;</li><li>String Processing;</li><li>HTTP root URL redirect;</li><li>HTML stub file generation;</li><li>HTTP general URL redirect; and</li><li>Local root page content.</li></ul>

Configuration Information.

Several pieces of configuration information are maintained on the interface in support of the Web redirect functionality. The value of each configuration item can be retrieved and set via SNMP. Table 1 (below) lists this configuration information. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1 -</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col2" align="center"><b>Configuration Information</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Configuration Item</entry><entry namest="col2" nameend="col2" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">xRootRedirectURL</entry><entry namest="col2" nameend="col2" align="left">The URL used for root page redirection. This is used when redirecting HTTP requests for the root URL.</entry></row><row><entry namest="col1" nameend="col1" align="left">xGeneralRedirectURL</entry><entry namest="col2" nameend="col2" align="left">The URL used for general redirection and for token substitution of the "(GeneralRedirectURL)" token.</entry></row><row><entry namest="col1" nameend="col1" align="left">xDomainName</entry><entry namest="col2" nameend="col2" align="left">The fully qualified domain name for the interface. This is used for token substitution of the "(DomainName)" token.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">xTypeTokenDefault</entry><entry namest="col2" nameend="col2" align="left">A flag controlling the interface type and peripheral type substitution behavior of the token substitution function.</entry></row></tbody></tgroup></table></tables>

String Processing.

String processing is performed on various strings which the interface passes to the browser. The specific string processing operations are described below. <ul id="ul0013" list-style="bullet"><li>Space substitution: Any "+" characters encountered in the string are converted to ASCII space characters.</li><li>Escape conversion: Any escape encoded characters which are encountered in the string are converted to their single character equivalent. Common characters in URL parameters passed to the interface which require escape encoding are set forth in Table 2 below.</li></ul><tables id="tabl0002" num="0002"><table frame="all"><title>Table 2 -</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col2" align="center"><b>Common Characters Which Require Escape Encoding</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Char</entry><entry namest="col2" nameend="col2" align="left">URL Encoding</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">"</entry><entry namest="col2" nameend="col2" align="left">%22</entry></row><row><entry namest="col1" nameend="col1" align="left">&lt;</entry><entry namest="col2" nameend="col2" align="left">%3c</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">&gt;</entry><entry namest="col2" nameend="col2" align="left">%3e</entry></row></tbody></tgroup></table></tables>

Token Substitution.

As certain tokens are encountered in a string, the interface substitutes the appropriate value. Table 3 below defines the token names/syntax and the values which are substituted. Token names are case-insensitive and are surrounded by the open and close parenthesis "(" and ")" as part of the token name syntax. <tables id="tabl0003" num="0003"><table frame="all"><title>Table 3 -</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col2" align="center"><b>Token Substitution</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Token Name</entry><entry namest="col2" nameend="col2" align="left">Substituted Token Value</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">(GeneralRedirectURL)</entry><entry namest="col2" nameend="col2" align="left">The value contained in the xGeneralRedirectURL configuration item.</entry></row><row><entry namest="col1" nameend="col1" align="left">(DomainName)</entry><entry namest="col2" nameend="col2" align="left">The value contained in the xDomainName configuration item.</entry></row><row><entry namest="col1" nameend="col1" align="left">(InterfaceMAC)</entry><entry namest="col2" nameend="col2" align="left">The 12 hexadecimal digit MAC address of the interface.</entry></row><row><entry namest="col1" nameend="col1" align="left">(InterfaceType)</entry><entry namest="col2" nameend="col2" align="left">A string indicating the interface type which can be used to customize a directory path or file name within a URL. If the xTypeTokenDefault configuration item is set to disable(0), then the string "Default" is the substituted value. If the item is set to enable(1), then normal token substitution is performed.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">(PeripheralType)</entry><entry namest="col2" nameend="col2" align="left">A string indicating the peripheral type which can be used to customize a directory path or file name within a URL. The string is the MODEL string from the peripheral's ID string with the spaces converted to underscore ("_") characters (<i>e.g.</i> HP_LaserJet_5Si). If the xTypeTokenDefault configuration item is set to disable(0), then the string "Default" is the substituted value. If the item is set to enable(1), then normal token substitution is performed.</entry></row></tbody></tgroup></table></tables>

HTTP Root URL Redirect.

The HTTP root page redirect function performs redirection of HTTP GET or HEAD requests for the root URL ("/"). When the interface receives an HTTP request for the root URL ("/"), it returns an HTTP response with a status code "moved temporarily" and a location field indicating the actual URL to access.

The location field value is produced by taking the xRootRedirectURL configuration item value and performing token substitution on this value. If the xRootRedirectURL item has not been configured, the interface reverts to its stand alone behavior.

HTML Stub File Generation.

HTML stub file generation allows dynamic generation of small HTML files with the content of the HTML file being passed in as a parameter on the request URL. This mechanism can be used to generate small HTML files containing an APPLET tag for invoking a JAVA applet and which have some portion of the HTML file body customized with information specific to a particular interface.

HTML stub file generation occurs when an HTTP GET or HEAD request is received for the "/stubgen" URL. The value of the ?body= parameter at the end of the request URL is used as the body of the returned HTML stub file. String processing is performed on the body of the HTML stub file before it is returned to the requester.

If the following request URL is specified: http:/jetdirect1.rose.hp.com/stubgen?body=this+is+the+body+of +the+HTML+stub+file

Then the returned HTTP header is: HTTP/1.0 200 OK

And the returned HTML content is: <ul id="ul0014" list-style="none" compact="compact"><li>&lt;HTML&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;TITLE&gt; stub file &lt;/TITLE&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;BODY&gt;</li><li>this is the body of the HTML stub file</li><li>&lt;/BODY&gt;</li><li>&lt;/HTML&gt;</li></ul>

HTTP General URL Redirect.

The HTTP general redirect function performs redirection of HTTP GET, HEAD, and POST requests for all URLs with a certain initial path component. When the interface receives an HTTP request for a URL that has an initial path component of "/redirect", it returns an HTTP response with a status code "moved temporarily" and a location field indicating the actual URL to access. The location field value is produced by taking the request URL, replacing the "/redirect" component with the value of the xGeneralRedirectURL configuration item, and performing token substitution on the resulting URL.

If the xGeneralRedirectURL item has not been configured, the interface returns an HTTP response with a status code.

Host Software Usage.

There are a number of ways in which host software can utilize the Web redirect functionality.

Example 1

This example shows the general HTML stub file and HTTP redirect usage. The example configuration is as shown in Tables 4 and 5 below. <tables id="tabl0004" num="0004"><table frame="all"><title>Table 4 -</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col2" align="center"><b>Example 1: Web Server Setup</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Content Server Setup</entry><entry namest="col2" nameend="col2" /></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">http : //server.rose.hp.com /Webjetadmin</entry><entry namest="col2" nameend="col2" align="left">Base URL for where the host software is installed</entry></row><row><entry namest="col1" nameend="col1" align="left">http : //server.rose.hp.com /Webjetadmin/java</entry><entry namest="col2" nameend="col2" align="left">Directory where JAVA applet/class files are stored</entry></row><row><entry namest="col1" nameend="col1" align="left">http : //server.rose.hp.com/Webjetadmin/java/Printerstatus.class</entry><entry namest="col2" nameend="col2" align="left">JAVA applet for printer status</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">http : //server.rose.rose.com/Webjetadmin/Webjetadmin.exe</entry><entry namest="col2" nameend="col2" align="left">URL for top-level UI home page (an "?addr=xxx" parameter causes top-level UI to display the specific page automatically for the interface/peripheral with that address)</entry></row></tbody></tgroup></table></tables><tables id="tabl0005" num="0005"><table frame="all"><title>Table 5 -</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col2" align="center"><b>Example 1: Interface Configuration</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Interface Configuration</entry><entry namest="col2" nameend="col2" /></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">printer1.rose.hp.com</entry><entry namest="col2" nameend="col2" align="left">xDomainName - pre-configured domain node name for the interface</entry></row><row><entry namest="col1" nameend="col1" align="left">http : //server.rose.hp.com/Webjetadmin/Webjetadmin.exe?addr=(lnterfaceMAC)</entry><entry namest="col2" nameend="col2" align="left">xRootRedirectURL - pre-configured home page redirect)</entry></row><row><entry namest="col1" nameend="col1" align="left">http://server.rose.hp.com/Webadmin</entry><entry namest="col2" nameend="col2" align="left">xGeneral Redirect URL - pre-configured general redirect URL (where host software is installed)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">enable(1)</entry><entry namest="col2" nameend="col2" align="left">xTypeTokenDefault - pre-configured interface-type and peripheral-type token substitution behavior</entry></row></tbody></tgroup></table></tables>

An example set of files and sequence of actions is as follows:

The top-level UI generator feeds an HTML page to the browser. This page contains a desired printer status hyperlink as follows: &lt;A HREF="http://printer1.rose.hp.com/stubgen?body="&lt;APPLET+CODE= "Printerstatus.class"+ CODEBASE="http://(InterfaceName)/redirect/java/"+ HEIGHT=500+WIDTH=500&gt;+&lt;PARAM+NAME=LANG+VALUE=E N&gt;+&lt;/APPLET&gt;"&gt;Printer Status&lt;/A&gt;

However, because some of the characters in the URL parameter need to be encoded, the actual printer status hypertext link is as follows: &lt;A HREF="http://printer1.rose.hp.com/stubgen?body=%22%3cAPPLET+ CODE=%22Printerstatus.class%22+CODEBASE=%22http:// (InterfaceName)/redirect/java/%22+HEIGHT=500+WIDTH=500% 3e+%3cPARAM+NAME=LANG+VALUE=EN%3e+%3c /APPLET%3e%22&gt;Printer Status&lt;/A&gt;

When the user follows the printer status hypertext link, the browser sends an HTTP GET request to the interface (printer1.rose.hp.com) with the following (note that the /java/ directory is always in a fixed position relative to the interface xGeneralRedirectURL path): GET /stubgen?body=%22%3cAPPLET+CODE=%22Printerstatus. class%22+CODEBASE=%22http://(InterfaceName)/redirect/java/% 22+HEIGHT=500+WIDTH=500%3e+%3cPARAM+NAME=LANG +VALUE=EN%3e+%3c/APPLET%3e%22 HTTP1.0

The interface processes the HTTP request for stub generation, and returns the following HTML page as a response (substitution was done on the "(InterfaceName)" token): <ul id="ul0015" list-style="none" compact="compact"><li>&lt;HTML&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;TITLE&gt; stub file &lt;/TITLE&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;BODY&gt;</li><li>&lt; <b>A P P L E T C O D E</b> = " <b>P r i n t e r s t a t u s . c l a s s</b> " CODEBASE="http://printer1.rose.hp.com/redirect/java/" WIDTH=500 HEIGHT=500&gt; &lt;PARAM NAME=LANG VALUE=EN&gt; &lt;/APPLET&gt;</li><li>&lt;/BODY&gt;</li><li>&lt;/HTML&gt;</li></ul>

The browser processes the HTML stub page, and sends an HTTP GET request to the interface (printer1.rose.hp.com) as follows: GET /redirect/java/Printerstatus.class HTTP1.0

The interface processes the HTTP request for redirect, and returns an HTTP response with the following information (the /redirect path was stripped and the server base URL inserted): HTTP/1.0 302 Moved Temporarily Location: http://server.rose.hp.com/Webjetadmin/java/Printerstatus.class

The browser processes the HTTP response, and sends an HTTP GET request to the content server as follows: GET /Webjetadmin/java/Printerstatus.class HTTP1.0

The content server processes the HTTP request and returns the contents of the JAVA applet file. [JAVA applet contents]

A browser accessing the interface root or home page directly sends an HTTP request to the Interface as follows: GET /HTTP1.0

The interface sends a HTTP response with the following fields (substitution was done on the "(InterfaceMAC)" token in the pre-configured interface home page URL redirect): HTTP/1.0 302 Moved Temporarily Location: http://server.rose.hp.com/Webjetadmin/Webjetadmin.exe?addr =080009123456

The browser processes the response and sends an HTTP request to the content server as follows: GET /Webjetadmin/Webjetadmin.exe?addr=080009123456 HTTP1.0

The content server processes the HTTP request, invokes the top-level UI generator, and returns an HTML page for the top-level Ul: [HTML page content for top-level UI]

Stand alone Root URL Behavior.

When the interface has not yet been configured with a xRootRedirectURL value it functions in stand alone mode because it cannot identify a content server to handle requests for its root page.

Stand alone options include: <ul id="ul0016" list-style="bullet"><li>Do not response to HTTP requests.</li><li>Respond with an HTML page containing text indicating the location of the WebJetAdmin software.</li><li>Respond with an HTML page containing simple peripheral/interface status and identify information and text indicating the location of the WebJetAdmin software.</li><li>Provide configuration pages equivalent to Telnet configuration capabilities.</li></ul>

HTTP Redirection.

The HTTP protocol supports the redirection of browser generated HTTP requests from one HTTP daemon to another. This is accomplished as follows: <ul id="ul0017" list-style="bullet"><li>The browser sends an HTTP request to an HTTP daemon specifying the request URL.</li><li>The HTTP daemon sends an HTTP response back to the browser with a status code "moved permanently" or "moved temporarily' and with the new URL given by the location field in the response. The HTTP daemon has considerable latitude in what the new URL is and can dynamically generate the new URL if it desires. The new URL can indicate an HTTP daemon on another machine (<i>e.g.</i> a content server).</li><li>The browser receives the HTTP response and then sends an HTTP request to the new URL where the actual content is stored.</li><li>The HTTP daemon processes the HTTP request and sends back a response to the browser with the actual content.</li></ul>

JAVA Applets Invocation.

A JAVA applet resides in a file which is loaded from an HTTP daemon (<i>i</i>.<i>e</i>. Web server) into a browser, and executed within the JAVA execution environment on that browser. A JAVA applet must be invoked via an APPLET tag from within an HTML file. The HTML APPLET tag has the following syntax (there may be other parameters between the applet start tag and end tag): <ul id="ul0018" list-style="none" compact="compact"><li>&lt;APPLET CODE=xxx CODEBASE=xxx HEIGHT=xxx WIDTH=xxx&gt;</li><li>&lt;/APPLET&gt;</li></ul>

The APPLET tag parameters are as follows: <ul id="ul0019" list-style="bullet"><li>CODE - specifies the name of the file containing the JAVA applet relative to the CODEBASE URL (<i>e.g.</i> Printerstatus.class);</li><li>CODEBASE - specifies the base URL of where the JAVA applet is located including the domain name and directory path (<i>e.g.</i> http://server.rose.hp.com/Webjetadmin/java/);</li><li>HEIGHT - reserved page area height in pixels; and</li><li>WIDTH - reserved page area width in pixels.</li></ul>

An HTML stub file to run a JAVA applet appears as follows: <ul id="ul0020" list-style="none" compact="compact"><li>&lt;HTML&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;TITLE&gt; Printer Status &lt;/TITLE&gt;</li><li>&lt;HEAD&gt;</li><li>&lt;BODY&gt;</li><li>&lt;<b>APPLET C O D E</b> = " <b>P r i n t e r s t a t u s . c l a s s</b> " CODEBASE="http://server.hp.com/Webjetadmin/java" WIDTH=500 HEIGHT=500&gt;</li><li>&lt;/APPLET&gt;</li><li>&lt;/BODY&gt;</li><li>&lt;/HTML&gt;</li></ul>

Loading and running a JAVA applet in a browser involves the following steps: <ul id="ul0021" list-style="bullet"><li>The user clicks on a screen area causing the browser to follow a hyperlink. The hyperlink URL is the URL for the HTML stub file.</li><li>The browser does an HTTP GET of an HTML stub file URL.</li><li>The HTTP daemon returns the contents of the requested HTML stub file. The HTML stub file contains the APPLET tag indicating the URL of the JAVA applet file. The browser reads and processes the HTML stub file contents and encounters the APPLET tag</li><li>The browser does an HTTP GET of the JAVA applet file URL. Normally, the browser reconnects to the HTTP daemon from which it received the HTML stub file to also get the JAVA applet file. However, if the CODEBASE parameter is specified in the HTML stub file, then the browser connects to the HTTP daemon URL specified in the CODEBASE tag to get the JAVA applet file.</li><li>The HTTP daemon returns the contents of the requested JAVA applet file. The browser reads the JAVA applet file contents, loads it into memory, and runs it within the JAVA execution environment.</li><li>The JAVA applet may then make SNMP/PML and/or HTTP accesses to collect needed information for the user interface presentation.</li></ul>

JAVA Security and Redirects.

The current JAVA security model imposes the constraint that an executing JAVA applet can only conduct network communication with the host from which the JAVA applet was originally loaded. Thus, a JAVA applet can only send SNMP packets to an interface if the browser loaded the JAVA applet from that interface via an HTTP GET.

However, using the HTTP redirect mechanism, it is possible for the JAVA applet to be stored on a content server rather than on the interface or peripheral, yet still function within the JAVA security constraints. To do so, the interface must respond to the HTTP GET of the JAVA applet with the HTTP moved temporarily status code and specify the actual location (URL) of the JAVA applet in the location field of the HTTP response.

In addition, an executing JAVA applet may reference and fetch a number of class files. These class files are located relative to, and along with, from wherever the JAVA applet was fetched.