header(); $ui->template_open(); $ui->message("The Uptimes Protocol (rev. 4.2)", ""); ?>

What is this document about?
This document will describe the 4th revision of the uptimes protocol, used to communicate between the uptime server and its clients.

HTTP Protocol
As of revision 4, data is sent using the HTTP protocol instead of using an own TCP/IP stream. This way clients behind a firewall/proxy can use the client too. In particular all clients POST a request to the uptime server which returns a simple text string displaying the result. To make sure nobody can alter the data of other hosts the uptime server requires authentication.

General information
In order to work, a client must...

The HTTP header
A header would look like this:

POST /server.html HTTP/1.1
Host: uptimes.noctumdesign.com
Connection: Close
User-Agent: upclient/4.20/myclient-1.00
Content-type: application/x-www-form-urlencoded
Content-length: 7225

The actual data
There should be a newline between the header and the data. The data should look something like this:

auth=fd1daaf6ad3cd5e574f158fc14346fd9&uptime=17126&load=0.12&idle=97&os=Linux&oslevel=2.2.13
The data consists of multiple 'key=value' pairs. All values should be url-encoded (so '@' should be '%40' etc.). Below are all possible keys described.

Return values
If the HTTP request was ok, the uptime server will return a string in the form "UP4: xxx sss...". On succes, xxx is 000 and sss... is an optional message. If an error has occured, xxx will be the error code and sss... the error string

Faking
Now you know the protocol, it's easy to write a client that fakes the uptime. Personally, I think hosts running Linux 2.4.x with uptimes over 3 years are not cool. Maybe you think different.


Updated for uptimes.noctumdesign.com - 11/26/2001, greatbotboy@noctumdesign.com
Original protocol - 12/12/2000, tgm@uptimes.net

template_close(); $ui->footer(); ?>