Category: HTML

Simple Perl Uploader with Progress Bar

This is a re-do of my previous blog post about Perl upload progress bars - my previous approach was completely wrong. By the time $q->upload(); is used, the file has already been received and stored in a temporary location, and so the "progress bar" in this case is really just guaging how fast the server can copy the file from one place to another on its hard drive.

So this post is how to really do a real working file uploader progress bar in Perl.

The basic steps required to do this include:

1. Set an onSubmit handler on your form that will set some ajax requests running in the background. The ajax will continuously poll your CGI script to see how the upload is going.
2. The upload CGI script needs to set an "upload hook" that CGI.pm calls repeatedly as the file is being received by the server. This hook can store the current progress of the upload somewhere, so that when the ajax pings it for the status, it can report the status.
3. Besides that everything else works the same as for a non-progress-bar upload. You can still do $q->upload(); and everything like before.

The source code needed for this is still amazingly short and concise, compared to the source codes you'll get when you download solutions from elsewhere.

Implementing this doesn't require any special Apache handlers or mod_perl or anything fancy like that.

Click the links below for the source codes to the HTML and CGI file, conveniently syntax-highlighted by vim:

¤ upload.html - the HTML file
¤ upload.cgi - the CGI script

You can download my full proof-of-concept test below:

¤ upload.tar.gz (6.6K)

Notice: this code is called "proof of concept"; it is NOT production-ready code. You should NOT download this if all you want is a complete plug-and-play solution you can quickly upload to your web server to get file uploading to work. I wrote this code only to show how to make a file uploader in the simplest way possible; this is useful for developers who only needed to know how this is done and who will write the code themselves to develop their production-ready file uploader.

If you want to treat this as a plug-and-play solution, I'm not your tech support about it. The code was never meant to be secure or useful to allow the general public to upload files through it. Session IDs are made up client side for example which is a bad idea in real use case scenarios, etc.

Quick Idea About CGI Security

Here's a random idea that just popped into my head: to help with the security of CGI scripts, certain HTML elements in the forms can be "tagged" in various ways depending on what their function will be once submitted.

So a textarea for leaving a comment can be tagged with name="ta-comment" (ta means textarea), and an input box meant for entering user names only could be tagged with name="user-login", and an input box meant for entering numeric zip codes can be tagged name="num-zipcode".

Then, the CGI script, when it first begins parsing the query string and form parameters, can automatically apply global filters to the inputs based on their tag. This way, every input that might potentially be used to access the filesystem can be filtered so that it doesn't contain any special characters that could introduce a vulnerability in the script, but fields that are meant to be more verbatim (i.e. comment boxes) can be left largely untouched.

# Create a CGI object
my $q = new CGI();

# This will hold your script's parameters
my $args = {};

# Get all the params.
foreach my $what ($q->param) {
my $is = $q->param($what);

# Filter the value based on the tag.
if ($what =~ /^num\-/) {
# Numbers only!
$is =~ s/[^0-9]//g;
}
elsif ($what =~ /^user\-/) {
# Usernames are numbers and letters only!
$is =~ s/[^A-Za-z0-9]//g;
}
elsif ($what =~ /^ta\-/) {
# Textareas turn their line breaks into <br>
$is =~ s/\n/<br>/g;
$is =~ s/\x0d//g;
}
$args->{$what} = $is;
}

So this way, as you write your front-end HTML code and the back-end Perl, you can tag all the inputs based on how the back-end code will plan on using them once submitted, and the code that collects the parameters when the form is submitted will be sure to format them in a consistent way. So, if your web application consistently doesn't allow quotation marks or HTML code in their text boxes, you can make the CGI automatically remove these things from all your incoming fields, and then just specially tag the ones that you want to be treated differently.

It would protect against accidental oversights by the programmer, and the end user can't do anything about it either. If the text box's name is "num-zipcode", the CGI script will always remove non-numbers when submitted and the user can't do anything about it. If they try to rename it with Firebug to be "text-zipcode" or anything like that, your CGI script won't use their version because it's not named as "num-zipcode."

I think I'll try implementing something like this next time I create a new web application.

Embedded Fonts for Firefox and IE 6

One of Firefox 3.5's new features includes support for the @font-face attribute of CSS 3, which allows you to embed a TrueType Font file on a web page, so that the user will see the font on your page even if they don't have the font installed on their computer.

This feature has been possible in Internet Explorer since version 4.0, but IE uses a variant of OpenType Font instead of TrueType. IE was the only browser to support such a thing for a long time, so it never really caught on.

Now that Firefox and other CSS3-supporting browsers are implementing @font-face for TTF, we can combine that feature with IE's support for EOT font files and get embeddable fonts to work on both browsers.

I have a demonstration here: Embedded Font Test. This page embeds my Rive font, which is available (in TTF form) from my Fonts page.

To convert TTF to EOT files, you can use Microsoft's WEFT tool which has been around since the dark ages, but I much prefer ttf2eot, hosted at Google Code. This is a no-nonsense tool that gets straight to the point of converting a font file without the hassle of dialogs that must be clicked through with WEFT. Oh, and there's conveniently a Windows executable already built, just grab it from the Downloads page.

Usage is pretty straightforward:

ttf2eot < Rive.ttf > Rive.eot

And then embedding the pair of fonts on a page that is compatible with both IE 6 and Firefox 3.5 (and I imagine other CSS3-compliant browsers, though I haven't tested them):

@font-face {
font-family: Rive;
src: url("Rive.eot") /* For IE 6+ */
}
@font-face {
font-family: Rive;
src: url("Rive.ttf") /* For CSS3 browsers inc. Firefox */
}
body {
background-color: #000000;
color: #FF9900;
font-family: Rive;
font-size: 16pt
}

IE 6 knows to ignore the TTF entry, and Firefox knows to ignore the EOT entry, as each browser can't display the opposite type of font.

Perl Uploader with Progress Bar

Update (11/25/09): This method is all wrong. Here is the correct way.

A thread on Tek-Tips came up recently about making a progress bar for a file uploader in Perl.

Investigating the issue more closely, I found a couple of commercial solutions (read: paid for), where even their free edition involves thousands upon thousands of lines of code, spread out across many different files. Nowhere to be found was a simple, straight-to-the-point example of how this could be done.

From poking around at what code I could find, I got the basic gist to it:

1. You have a regular file upload form as usual
2. When hitting Submit, a JavaScript callback on the submit button provokes some Ajax code to start ticking, and returns true, allowing the form to submit to the CGI script as normal.
3. The CGI script accepts along with your file, an "action" of "upload" - this instructs the CGI file to accept your uploaded file, create a session file and begin saving it to disk.
4. While your browser is waiting for the CGI script to finish processing your form, ajax is running in the background polling the CGI script with a different question: "action" = "progress"
5. When the CGI is polled for the progress of the uploaded file, it checks how big the file was, and how much has been saved already, and returns some simple numbers.
6. JavaScript, still running on your file upload page, uses these numbers to update the page to show you the current progress.

It looks like this:

If that sounds complicated, it really isn't. 77 lines for the CGI script, and 126 lines for the HTML page, including the JavaScript (only 60 lines of JavaScript).

The screenshots, code, and download link follow.

Source Code:

upload.html (the HTML form and JavaScript)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<title>File Upload Test</title>
<style type="text/css">
body {

background-color: white;
font-family: Verdana;
font-size: small;
color: black
}

#trough {
background-color: silver;
border: 1px solid black;
height: 24px

}
#bar {
background-color: #669900;
height: 24px;
width: 1%

}
</style>
</head>
<body>

<h1>File Upload Test</h1>

<div id="progress" style="display: none; margin: auto; width: 350px">
<fieldset>
<legend>Uploading...</legend>

<div id="trough"><div id="bar"></div></div>
Uploaded: <span id="uploaded">0</span>/<span id="size">0</span><br>

Percent: <span id="percent">0</span>%
</fieldset>
</div>

<div id="form" style="display: block; margin: auto; width: 350px">
<fieldset>
<legend>Upload a File</legend>

<form name="upload" action="upload.cgi" method="post" enctype="multipart/form-data" onSubmit="return uploadFile(this)">

<input type="hidden" name="action" value="upload">
File: <input type="file" name="file" size="20"><br>

<input type="submit" value="Submit File">
</form>
</fieldset>

</div>

<div id="debug"></div>

<script type="text/javascript">

// When the form is submitted.
function uploadFile(frm) {
    // Hide the form.
    document.getElementById("form").style.display = "none";

    // Show the progress indicator.
    document.getElementById("progress").style.display = "block";

    // Wait a bit and make ajax requests.

    setTimeout("getProgress()", 1000);

    return true;
}

// Poll for our progress.
function getProgress() {
    var ajax = new XMLHttpRequest();

    ajax.onreadystatechange = function() {
        if (ajax.readyState == 4) {

            gotProgress(ajax.responseText);
        }
    };

    ajax.open("GET", "upload.cgi?action=progress&session=my-session&rand=" + Math.floor(Math.random()*99999), true);

    ajax.send(null);
}

// Got an update
function gotProgress(txt) {

    document.getElementById("debug").innerHTML = "got: " + txt + "<br>\n";
    // Get vars outta it.

    var uploaded = 0;
    var size = 0;
    var percent = 0;

    var stat = txt.split(":");

    // Was it an error?
    if (stat[0] == "error") {

        document.getElementById("debug").innerHTML += "error: " + stat[1];
        setTimeout("getProgress()", 1000);

        return false;
    }

    // Separate the vars.
    var parts = stat[1].split("&");

    for (var i = 0; i < parts.length; i++) {
        var halves = parts[i].split("=");

        if (halves[0] == "received") {
            uploaded = halves[1];

        }
        else if (halves[0] == "percent") {

            percent = halves[1];
        }
        else if (halves[0] == "size") {

            size = halves[1];
        }
    }

    document.getElementById("debug").innerHTML += "size:" + size + "; received:" + uploaded + "; percent:" + percent + "<br>\n";

    // Update the display.
    document.getElementById("bar").style.width = parseInt(percent) + "%";

    document.getElementById("uploaded").innerHTML = uploaded;
    document.getElementById("size").innerHTML = size;
    document.getElementById("percent").innerHTML = percent;

    // Set another update.
    setTimeout("getProgress()", 1000);
    return true;

}
</script>

</body>
</html>

upload.cgi (the CGI script)

#!/usr/bin/perl -w

use strict;

use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);

my $q = new CGI();


# Handle actions.
if ($q->param('action') eq "upload") {
# They just submitted the form and are sending a file.

my $filename = $q->param('file');
my $handle   = $q->upload('file');
$filename =~ s/(?:\\|\/)([^\\\/]+)$/$1/g;

# File size.

my $size = (-s $handle);

# This session ID would be randomly generated for real.
my $sessid = 'my-session';

# Create the session file.

open (CREATE, ">./sessions/$sessid") or die "can't create session: $!";
print CREATE "size=$size&file=$filename";
close (CREATE);

# Start receiving the file.

open (FILE, ">./files/$filename");
while (<$handle>) {
print FILE;
}
close (FILE);

# Delete the session.

unlink("./sessions/$sessid");

# Done.
print $q->header();
print "Thank you for your file. <a href=\"files/$filename\">Here it is again</a>.";
}

elsif ($q->param('action') eq "progress") {
# They're checking up on their progress; get their sess ID.
my $sessid = $q->param('session') || 'my-session';
print $q->header(type => 'text/plain');

# Does it exist?

if (!-f "./sessions/$sessid") {
print "error:Your session was not found.";
exit(0);
}

# Read it.

open (READ, "./sessions/$sessid");
my $line = <READ>;
close (READ);

# Get their file size and name.

my ($size,$name) = $line =~ /^size=(\d+)&file=(.+?)$/;

# How much was downloaded?

my $downloaded = -s "./files/$name";

# Calculate a percentage.
my $percent = 0;
if ($size > 0) {
$percent = ($downloaded / $size) * 100;
$percent =~ s/\.(\d)\d+$/.$1/g;
}

# Print some data for the JS.

print "okay:size=$size&received=$downloaded&percent=$percent";
exit(0);
}
else {
die "unknown action";
}

Notes on this code: it's just a proof of concept. You'd want to handle the sessions better. Here the session ID is hard-coded as "my-session" -- that wouldn't work in real life. But it's just a barebones working implementation of a file upload progress bar, with all the crap cut out and does specifically what it's supposed to. Others should find it useful, so you can download it.

Download: upload.tar.gz

Update (11/25/09): This method is all wrong. Here is the correct way.

Query String Delimiter?

Some length of time ago, I got the idea to start using the semicolon (;) instead of the ampersand (&) as a delimiting character in query strings. For instance:

<a href="/index.cgi?p=blog;tag=General">
as opposed to
<a href="/index.cgi?p=blog&tag=General">

The reasoning behind it was something along these lines:

• The W3C HTML Validator refused to validate my pages as HTML 4.01 Strict, citing that all those "&" characters should be fully typed out as "&", because HTML 4.01 no longer allows a single & without any kind of escape sequence following it.
• YaBB Forum, my favorite forum software for being Perl and not dependent on SQL, was using semicolons instead of ampersands.
• The Perl CGI module supports both forms of delimiters, so what's it matter?

And then, I was poking at some of my incoming referring URLs, many of which were Google search results that matched some of my blog entries. And this is where the semicolon-as-delimiter idea falls apart: apparently, in Firefox at least, those semicolons have a tendency to be escaped with the URI sequence %3B.

So, http://www.cuvou.com/?p=blog;id=36 looks right in the Google search results, but after it gets chewed up with Google's outgoing statistic gathering and finally accessed by the browser, the latter part of that request comes to my site looking more like this: /?p=blog%3Bid=36. CGI.pm has no idea what to make of this and it can't be blamed. I've tried substituting it in $ENV{QUERY_STRING} before CGI.pm can get its hands on it, but it doesn't help.

So effectively the user is greeted with a "Forbidden" page of mine, which was fired because the value of "p=" contains some invalid character (notably, that % symbol there).

So there's a conundrum here: semicolons as delimiters works as far as CGI is concerned, and it perfectly validates as HTML 4.01 Strict, and you don't need to write "&" all the time inside your internal site links. I mean seriously, how ugly is this HTML code?

<a href="/index.cgi?p=blog&amp;id=36">

It validates, it works as expected provided you're using it "properly", however it breaks your links in Google and possibly other search engines, at least in Firefox.

My temporary hack of a solution:

For my CMS, none of my links are "properly" written to begin with. They're like <a href="$link:blog;id=36"> which is translated on-the-fly, so it was fairly trivial to change the code to fix these things on the way out the door.

For the W3C's HTML validator, my links are translated to include the full and proper & text. It's ugly and I'm only glad I don't have to write the links like that directly; my Perl code does it for me.

The other half of the dirty hack is to detect when a troublesome URL has been linked to: particularly if %3B is found. If so, the CGI fixes the query string and sends an HTTP 301 redirect to the proper version of the URL, using the real semicolons (I could replace them with &'s here, but, why? The CGI module takes care of it anyway ).

I'll have to investigate what other web developers do with their query string delimiters...