Counter Program Notes

Look around the WWW Lab

Counter Types

CGI Script with GET Arguments

That is to say arguments are appended to the end of the URL as a query string. These arguments can also include this EG:

<IMG SRC="/cgi-bin/counter?cnt=counter">

Also other options can be added, such as: font to use, increment or don't increment, type of image to output, format of number (EG: number of digits, include leading 0's, space's or nothing, and if number is decimal, hexadecimal, roman!).

<IMG SRC="/cgi-bin/counter?cnt=counter&font=odometer&noinc">

Note however that GET arguments for images are also confusing to the early web clients (Why would an image need such arguments?). Also with get arguments, unless you add a suffix to the end of the option list these clients also will NOT know what type of image they are downloading. Here is a IMAGE URL which should work on most clients.

<IMG SRC="/cgi-bin/counter?cnt=counter&type=.gif">

Using this method the URL's can become very long, with lots and lots of arguments. Also if the counter program allows you to specify the amount to increment, or worse, set the counter to a specific value,your counter will not be secure as someone in the world could just reset your counter on a whim. Thus destroying its usfulness as a counter.

This method however will work with both cgi-bin counters and cgi scripts outside cgi-bin directories. The other method will only work with the former.

CGI Script with Path Information

A CGI program which is located in a cgi-bin can have the path continue after this program. This path is also translated by the server using the servers, document root, user home page directories and any other aliases it is using. This means that you can use this method to tell the client which counter file(s) it should work with.

For Example:

<IMG SRC="/cgi-bin/counter/~user/counter.cnt">

can be used to tell a counter CGI program to increment the counter stored in the file ``counter.cnt'' within the home pages of ``user''.

Note however that this will not work on older web clients for the reasons mentioned above. As such I recommend that the img tag be chnaged to...

<IMG SRC="/cgi-bin/counter/~user/counter.gif">

to keep older web clients happy, the counter program then only needs substitute ``.cnt'' for the ``.gif'' suffix to find the counter data file.

Other options for the counter, like font, number format, length, etc. could be added to the above with...

``GET'' arguments (and again breaking our setup for older web clients)

stored in the same file as the counter data

on in another file with a different suffix (like ``.dat'')

I myself wrote a program using this path method. My own Counter the counter data is stored with the suffixes ``.cnt'' while the number format (as a printf format string) and the directory to get the font images to use is stored in another ``.dat'' file.

Counter CGI Script

This use to be a most common counter method. Basically you call a CGI script with outputs the an image of the incremented counter. EG:

<IMG SRC="/cgi-bin/counter">

This is relatively easy to setup and if your server allows CGI execution outside ``cgi bins'' you can even use a local counter script.

<IMG SRC="counter.cgi">

This simple form of script however has no means of specifing which counter you are using. This can be remindied by adding options to the script.

Server Side include Counters (SSI)

This type of counter uses a feature of some WWW servers called server-side-includes (SSI), which is when the server on reading the HTML file sees a special tag and replaces this tag with the contents of another file or the output of a program.

The simplest of these is for a SSI to call a simple script to increment a counter file, and output the value as text.
EG: the SSI (which looks like a HTML comment)...

<!--exec cmd="inc_counter.pl" -->

is replaced with...

793 Accesses

More complex SSI output <IMG> tags for the counter.
EG: the same SSI above generates each individual digit images...

<IMG SRC="digit/7.gif"><IMG SRC="digit/9.gif"><IMG SRC="digit/3.gif">

OR: create a temporary image file (to be removed/updated later) and point to it.

<IMG SRC="tmp/cnt.gif">

The advantage of server side include counters are

The scripts are extremely simple

easily customisable for your own pages

Client users can not figure out the counter system as the html source received does not contain it any more.

However the disadvanages are

You have to have a web server with SSI (NCSA httpd for example)

The SSI will have to be turned on (they are optional)

one one counter per script only, as it is not easy to set up a multiple counter SSI program.

WWW Counter Server

This as far as I could tell was the first `counter' system for www pages. Basically a separate specially designed (simplistic) WWW server was created on a different port (eg: 8987) or on a different host entirely. HTML pages would request specific counter image which this server would lookup the appropriate data file, increment it, and then generate the requested image for that counter.

The advantages, are that the one server can handle all the counters required, for any machine around the world, unlike most other counters methods above which can only use locally stored counters.

For example:

http://counterhost.domain:port/font/counter.type

could be used to request the counter `counter', on the `counterhost' (could be the same machine) at the port given. This server would output the current count in the requested `image type' using the font `font' (optional). Also any client program would never know that anything was out of the ordinary, except that the image came from a different WWW server.

The counter server itself does not need to run continuously like a real WWW server but could be run on request by the `Inetd'. In fact by using inetd, you don't even have to bother with sockets and ports, etc. as inetd automatically connects standard input and output to the connected socket. In other words, you just recieve the Mime request from STDIN and output the final Mime Image to STDOUT.

I had created a simple version of a counter server. Mine however only understood how to generate X bitmaps. Actually it was a perl'ed copy of the first ever counter program I had ever seen. This counter program was created long before the advent of CGI, when script were still getting arguments insecurally on the command line!

Such servers however can be quite complex, as it does have to understand the HTTP protocol and normally would require superuser access to set up. As such while these were the first such counters they are rarely seen today.