Encoded URL
First, define two routines that can do the grunt work of
crushing and uncrushing your parameters, which for the sake
of argument are being stored in a
HASH:
use MIME::Base64;
sub Crush
{
return shift(@_).MIME::Base64::encode (join ("\x00", @_), "");
}
sub Uncrush
{
my ($q) = shift;
return split (/\x00/, MIME::Base64::decode($q->path_info()));
}
This is, of course, assuming you don't have any NULL (ASCII 0)
characters in your data. If you do, this code will break, but
it will work fine on normal ASCII text. Additionally, it
uses "path_info()" from
CGI.pm, which you should be using
anyway.
You could tie them into your program like so:
my (%data) = ( 'x' => 'y' ); # etc.
$url = Crush ("http://www.xyzco.com/foo.cgi?",%data);
# Or, on the receiving end...
my ($q) = new CGI;
my (%data) = Uncrush ($q);
It all ends up as a great big pile of goo as far as the
user is concerned, but it isn't encrypted to any great
degree. If you wanted, you could MD5 encrypt it, PGP it, or
whatever strikes your fancy, before MIME::Base64::encode(),
with the opposite on the receiving end, of couse.
Server Side Data
An intelligent alternative to this "encoding" is to keep the
data on the server. As you mentioned, long URLs are a problem
for some e-mail programs, and certainly more users. To keep
the URL to an absolute minimum, you could store all of the
data in a database on the server side and pass only a key
to the client.
Basically, your URL would contain a text key like "AxZLkFlG"
which is a randomly created string that the server would use
to identify that session. You could then store all of your
data server side.
The downside to this approach is that the
data has to be preserved for extended periods of time,
because if the server data is "expired", the URL becomes
virtually useless. If you expect the users to re-visit
six or eight months from now, that would translate to a six
or eight month history of data, which can get quite large,
depending on your application.
Additionally, if a user sends a copy of the URL to five
friends, they will all be modifying the same database entry,
which can lead to some unsavory variable "bleed" between
their sessions. This can be very dangerous, especially
for e-commerce applications.
If you have no idea when the user is going to re-visit,
and you want to preserve the state of the program
indefinitely, you have to pack all the data into the URL.
Base64 expands the content moderately, so the URLs will
always be longer using this method, but this can be
minimized if you compress it before encoding (i.e. LZW
encoding, like that used in gzip).