To serve its Web page the Rabbit module uses HTTP functions

an article added by: Daniel R. at 12062007


In: Root » » Ethernet » To serve its Web page the Rabbit module uses HTTP functions

French Spanish Portuguese Italian German Japanese Chinese Korean Russian Arabic

Rabbit Real-time Web Page

To serve its Web page, the Rabbit module uses HTTP functions and structures provided in Dynamic C to serve the Web page’s file on request. The main program loop updates the time variables once per second.

Page Design

Listing 6-2 is the HTML code for Network article 6-1’s Web page. The page uses HTML tags to advise the browser how to display the page’s contents. Each tag consists of text enclosed by angle brackets ( ). The In Depth section of this networking tutorial has more details about HTML tags and how to use them. For now, the relevant section of the code is the five lines that each begin with a paragraph tag (<p>). A paragraph tag tells the browser to display the information that follows in a new paragraph. The first paragraph tag causes the browser to display the text, “This Rabbit program has been running for:”. Each of the four lines that follow contains a Server Side Include #echo directive that inserts the value of a variable on the page. A Server Side Include directive uses the same delimiters as an HTML comment. A comment, which is text that the browser ignores and doesn’t display, is enclosed by <!-- and -->. On receiving a page that contains an HTML comment, the browser displays the page the same as if the comment and its delimiters weren’t present. Another use for comment delimiters is to enable a page to specify Server Side Include (SSI) directives that the server executes before serving the page to the browser. Before serving a page containing an SSI directive, the server executes the directive and replaces the delimiters and the text between them with the result of executing the directive. If for some reason the server doesn’t support the directive, the server ignores the directive and the browser treats the directive as a comment, which isn’t displayed.

The #echo directive tells the server to replace the comment tag and its contents with the value of the named variable. For example, in the first directive, the server replaces <!--#echo var="days"--> with the value of the variable days on the server. If days equals 5, the browser receives and displays Days: 5. The In Depth section of this networking tutorial has more details about #echo and other Server Side Includes.

TINI Real-time Web Page

To use a TINI to serve Web pages with dynamic content, you have a few choices. Your first thought might be to use the HttpServer class provided with the TINI’s operating system. However, this built-in Web server can only serve static pages. Serving dynamic data would require changing the data in the stored pages whenever the content changes. It’s more efficient to retrieve the dynamic data on request and insert it in the page as it’s being served. Another option is to install and run a server program that supports Java servlets. A servlet is a software component that can respond to user input and generate dynamic content for Web pages. In most cases, servlets are the most effective and time-saving way to enable a Web server to serve dynamic content. Chapter 7 has more about servlets and how to use them.

A third option is to write a basic Web server that uses the ServerSocket class and adds dynamic content as it serves its pages. For some low-volume applications that serve one or a few pages, this kind of home-brewed server can do the job without adding too much complexity. The example in this networking tutorial uses the ServerSocket class to create a basic server that serves a page that displays the amount of time the TINI has been up and running. Whether or not you decide to use this approach, the code in this application is interesting as a demonstration of the responsibilities of a Web server. The Web server responds to requests to connect to a specific port. When a connected host sends an HTTP request for a supported page, the server calculates the values of variables the page contains, writes the contents of the page to the socket, and closes the socket.

Protocols for Serving Web Pages

The examples in this networking tutorial showed how Web browsers use the hypertext transfer protocol (HTTP) to request Web pages, and the Web pages themselves are encoded using the hypertext markup language (HTML). In addition, some pages use server-side include (SSI) directives to enable a Web page to display dynamic data or to add other capabilities not available with HTML alone.

This section has more details about HTTP, HTML, and SSI, with the focus on how embedded systems can use each in serving pages with dynamic content.

Using the Hypertext Transfer Protocol

HTTP is one of many standard application-level protocols used in network communications. Network article 6-5 shows the location of HTTP in a network protocol stack. Although in theory an HTTP communication can use any reliable protocol to reach its destinations on a network, in practice just about all network stacks pass HTTP communications through TCP and IP layers. An 266 application that uses HTTP may be a Web browser, which requests Web pages, or a Web server, which returns Web pages on request. Anyone who has browsed the Internet has used HTTP. When a browser sends a request for a Web page onto the network, the request contains a URL that identifies the location and file name of the page. Chapter 4 described how a network uses the information in the URL to determine where to route a communication.

On learning the IP address that is hosting the desired Web page, the client requests to open a TCP connection with the computer at that address. By default, Web servers serve pages on port 80. If a server is using a different port number, the URL specifies the number, as explained in Chapter 4. When the connection has been established, the browser sends a message containing an HTTP request for a page, and the receiving computer responds by serving, or sending, the Web page to the requesting computer over the TCP connection. A benefit of using Web pages to provide information is that the browser interface is universal. If you place a Web server on the Internet, anyone with a browser and an Internet connection can view the server’s pages. Search engines make it possible for users to find your page even if they don’t know the IP address or domain name. Web pages don’t have to be on the Internet, however. You can make a page available only within a local network. If desired, you can also restrict access by specifying what IP addresses can access a page or by requiring a password to access the page. In any case, you don’t have to limit communications to users who are using specific hardware or software. As the examples in Chapter 7 show, a server can also receive information from a browser. A Web page can enable users to send information to the computer that is serving a page, and the computer can use this information for any purpose.

HTTP Versions

HTTP version 1.1 is specified in RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. RFC1945 contains the previous versions, HTTP 1.0 and 0.9.

Version 1.1 adds capabilities for conserving network bandwidth, improving security and error notification, enabling clients to specify preferred languages or character sets, and allowing more flexible buffering by dividing data into chunks. Many embedded systems serve small and simple Web pages. These systems may gain little benefit in supporting HTTP 1.1 and thus may use 1.0 for simplicity. HTTP 1.0 servers must also respond appropriately to requests from 0.9 clients. A browser that supports HTTP 1.1 should have no trouble communicating with a 1.0 server. Dynamic C’s HTTP server complies with HTTP 1.0. The Tynamo Web server used in Chapter 7’s TINI examples implements the required elements in HTTP 1.1. Probably the main reason an embedded system might use HTTP 1.1 is its support for persistent connections, which can reduce the number of connections the server must open and close. With HTTP 1.0, each request requires a new connection. If a client requests a Web page that contains several links to images, the request for the page as well as each request for an image requires its own connection, which in turn requires the server and client to do the handshaking to open and close each connection. Requesting multiple pages within a short time also requires a new connection for each page. In contrast, with HTTP 1.1, the default behavior is persistent connections, where a connection is left open until either the client or server determines that the communication is complete or the server closes the connection after a period of no activity. The RFC documents spell out the minimum capabilities that an HTTP server must have. The requirements vary with the HTTP version.

Elements of an HTTP Message

An HTTP message consists of an initial request or status line, optional message headers, a blank line, and an optional entity body. (HTTP 0.9 doesn’t support status lines or headers.) HTTP supports two types of messages, requests and responses. A client sends a request to ask a server for a resource, and the server returns a response containing the resource or status information.

On receiving a page that includes images, the client typically sends a GET request for each image. In addition to the GET method, HTTP 1.0 and later define the HEAD and POST methods (Table 6-1). HEAD is similar to GET except that the server returns only the headers it would send in responding to a GET request for the resource, but not the resource itself. The POST method enables a client to send data to a resource on the server. The server passes the data received in the message body to the program, process, or other resource specified in the request line. The named resource uses the data. A common use for POST is to enable users to send data entered on a form to a CGI program, which processes the data and sends a response to the client. (Chapter 7 has more about CGI.) But a POST request can specify any resource, and the resource can use the data in any way. The HTTP 1.1 standard says that all general-purpose servers must at minimum support the GET and HEAD methods. HTTP 1.1 defines additional methods. One that embedded systems might use is PUT, which like POST, enables the client to send data to the server. But instead of naming a resource to receive the message body’s data, a PUT request names a file or other entity where the server should store the message body’s data. PUT can be useful for file transfers, where the request line names the file on the server where the server should store the received data. HTTP 0.9 supports only the GET method, and the request line includes only the request and the URL, not the HTTP version. If no HTTP version is specified, the server should assume it’s version 0.9. Methods specified in requests must be upper case and followed by a space.

legal disclaimer

Our website is not responsible for the information contained by this article. Web-articles is a free articles resource.
Suggestion: If you need fresh, daily updated content for your website, feel free to use our service. Click here for more information.

related articles

1. Dallas Semiconductor DSTINIm400
Dallas Semiconductor DSTINIm400 (TINI) At a Glance: A fast microcontroller with an enhanced 8051 architecture, plenty of I/O, an operating system, and a Java virtual machine (JVM). Ethernet support: 10BASE-T, 100BASE-TX Typical Uses: applications that need speed, lots of I/O, or a CAN interface. Source: Dallas Semiconductor (www.dalsemi.com). Dallas Semiconductor is a wholly owned subsidiary of Maxim Integrated Products. Hardware. TINI stands for Tiny InterNet Interface. Technically, the TINI isn’t a ...

2. The MCF5282 supports a subset of the Motorola 68000
Ethernet support: 10BASE-T The MCF5282 supports a subset of the Motorola 68000. Typical use: Applications that use Java and require speed. Source: Systronix (www.systronix.com). Hardware. The TINI isn’t the only option for Java programmers. Systronix’s JStik board (Network article 3-8) contains aJ-100 microcontroller from aJile Systems Inc. The aJ-100’s native execution of Java bytecodes results in very fast performance. The chip is base...

3. Ubicom IP2022 Wireless Network Processor
Special-Purpose Modules Ubicom IP2022 Wireless Network Processor. In addition to products that provide a complete generic system for networking, a variety of modules and chips are available to handle specific tasks. Some products can interface to just about any CPU. If you have an existing product or a CPU that you want to use, one of these modules may provide a way to add networking capability. This section describes a selection of products. Lantronix Device Server At a glance: enables any device with an ...

4. EDTP Electronics Packet Whacker
EDTP Electronics Packet Whacker At a glance: An Ethernet interface on a circuit board with headers for connecting to a CPU. Typical use: adding Ethernet to any microcontroller circuit. Ethernet support: 10BASE-T Source: EDTP Electronics (www.edtp.com) Hardware. The Packet Whacker (Network article 3-11) from EDTP Electronics is an Ethernet interface only. The circuit board contains a Realtek RTL8019AS Ethernet controller, an RJ-45 connector, two headers that bring out the si...

5. NE2000 Compatibility
NE2000 Compatibility A term you’re likely to hear in reference to program code for network controllers is NE2000-compatible. The NE2000 was an early and popular PC network interface card from Novell. The card contained National Semiconductor’s DP8390 controller. Software for systems that use the ’8390 or a compatible chip has come to be known as NE2000-compatible code. A major feature of the ’8390 is its set of internal registers. By reading and writing to the registers, a CPU can c...

6. Using the Internet Protocol in Local and Internet Communications
The protocols in the IEEE 802.3 Ethernet standard enable the computers in a local network to exchange messages with each other. In practice, most Ethernet networks also use Internet protocols such as TCP or UDP and IP. These provide defined and well-supported methods for accomplishing common tasks such as flow control and flexible addressing and routing of messages. Messages that travel on the Internet must use IP. And because TCP and UDP are designed to work along with IP, local communications that use TCP or UDP also use...

7. There are several options for obtaining an Internet connection
Technologies for Connecting There are several options for obtaining an Internet connection. A long-popular way for home users to connect to the Internet is via dial-up connections on phone lines. For higher speeds, alternatives are a Digital Subscriber Line (DSL), an Integrated Services Digital Network (ISDN) line, or a cable modem. Satellite connections are also possible. Table 4-1 compares the capabilities of the different methods. Not every connection type is available in all locations. Depending on ...