Home ›

Introducing AOLserver

Issue 101

From Issue #101
September 2002

Sep 01, 2002  By Reuven M. Lerner
 in
Using AOLserver is not nearly as difficult or challenging as you initially might expect.
Tcl Programs

While AOLserver is undoubtedly an excellent HTTP server for static documents, you're unlikely to use it for that. It's far more common to create dynamic pages using Tcl.

The easiest and simplest way is to create a Tcl program that returns HTML. To do this, create a file in the pageroot that ends in the .tcl extension. It can create any Tcl that you want; the most important thing, however, is that it end with ns_return—a Tcl procedure defined by AOLserver that takes three arguments: 1) a numeric HTTP response code (such as 200 or 404) that indicates the success or failure of the program's execution, 2) a “Content-type” header that describes the type of content that is being returned and 3) the actual content to return to the user.

For example, here is a simple “Hello, world” program:

ns_return 200 text/html "<html>
<head>
    <title>Testing</title>
</head>
<body>
     <p>Hello, world</p>
</body>
</html>"

If you stick the above program in the pageroot directory as hello.tcl and load it into your browser, you will get the literal contents of the file returned to you. That's because we need to reconfigure AOLserver to allow .tcl pages within the pageroot. We do this by setting the enabletclpages parameter to true within the ns/server/${servername} section: 

ns_section "ns/server/${servername}"
ns_param   enabletclpages  true
Once you have made this change, you can restart AOLserver and retrieve hello.tcl once again. This time, you should see HTML output rather than the verbatim, text/plain output.

A .tcl page can do a host of different things: connecting to a database, retrieving information from XML files to retrieving information from across networks or receiving information from an HTML form. Because Tcl comes with a variety of string-manipulation commands, you can parse the input and interpolate variables into the output in a wide variety of ways.

Note that the Tcl is interpreted within AOLserver, rather than as an external process. This means that such .tcl files execute much faster than a CGI program would; in many ways, they run similarly to Perl programs in mod_perl.

It's true that .tcl files are great when a programmer is creating the outgoing HTML. But as I (and others) have learned from bitter experience, graphic designers generally are unprepared to modify HTML that appears within source code files. For this reason, many web developers have switched over to templates—be they ASP, JSP, HTML::Mason, DTML or a variety of other similar technologies. AOLserver comes with its own built-in templating system, known as ADP (AOLserver Dynamic Pages), whose syntax is suspiciously similar to Microsoft's ASP. Code that you want to execute goes within <% and %>, while the code that outputs a value into the surrounding HTML goes within <%= and %>. For example:

<% set foobar "abcdef" %>
<head>
    <title>Testing</title>
</head>
<body>
    <p>Hello, world</p>
    <p>Hello, <%= $foobar %></p>
</body>
</html>

Sites larger than a few pages probably will want to share some Tcl code. The easiest way to do this is to create one or more .tcl files that define procedures that AOLserver will load at startup time. These procedures then will be available to all of your .tcl and .adp pages. To enable this functionality, we must add the following to our sample-config.tcl file: 

ns_section ns/server/${servername}/tcl
ns_param   library \
  ${homedir}/servers/${servername}/tcl
ns_param   autoclose      on
ns_param   debug          true
Since our server name is server1, any .tcl file that we place in /usr/local/aolserver/servers/server1/tcl will be loaded when AOLserver starts up. For example, I added the file foo.tcl to that directory, whose contents consisted of: 
proc return_hello {} {
    return "hello"
}
I restarted AOLserver (which is necessary in order for it to read Tcl library files) and modified hello.adp to read: 
<% set foobar "abcdef" %>
<% set hello [return_hello] %>
<head>
    <title>Testing</title>
</head>
<body>
    <p>Hello, world</p>
    <p>Hello, <%= $foobar %></p>
    <p>Hello, <%= $hello %></p>
</body>
</html>
Now the value of the “hello” variable is set to the output from my return_hello proc, which in this case is nothing more than the word hello.

Because you must restart AOLserver in order for it to load library Tcl procedures, I've often found it easiest to define new procedures within <% %> sections in my ADP pages. Once I see that the procedure works correctly, I move its definition to the library directory and restart AOLserver only once.

ADP and .tcl pages are fine for documents that contain some dynamic content. But sometimes you want to associate programs with a URL without necessarily creating a document on disk. We easily can take care of this by defining a Tcl procedure in our library file and then registering that procedure with a particular URL using the AOLserver ns_register_proc command:

proc http_hello {} {
  ns_return 200 text/html "<html>
                           <head><title>Hello!
                             </title></head>
                           <body><p>Hello!
                             </p></body>
                           </html>"
}
ns_register_proc GET /hello http_hello

If you put this Tcl code in a file that sits within the library directory we defined earlier, restart your server and point your browser to /hello, you will see the output from our http_hello procedure.

I've been programming in mod_perl for several years and am still impressed by the ease with which you can create new dynamic pages with AOLserver and ns_register_proc. Moreover, you can register different procedures for GET and POST requests. You even can register filter procedures that can monitor or change the output generated by another page.

______________________

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions