A while back Jason Silver was having issues getting a site to work. He discovered that the site's host was using CGIWrap to handle cgi scripts which was adversely affecting blosxom.cgi. Geoffrey Alexander sent him a fix, which goes in the blosxom.cgi...

# Path Info Magic
# Take a gander at HTTP's PATH_INFO for optional blog name, archive
yr/mo/day
##This is the fix for CGIWrap
#my @path_info = split m{/}, path_info() 
     || param('path'); # <--changed to:
my @path_info = split m{/}, $ENV{QUERY_STRING};
##

In otherwords, my @path_info = split m{/}, $ENV{QUERY_STRING}; replaces my @path_info = split m{/}, path_info() || param('path');. However Jason discovered this didn't completely resolve the issue. He found that this code, which replaces the same single line in blosxom.cgi, did work...

my $script_uri = $ENV{'SCRIPT_URI'}."/";
$script_uri =~ s/$url\///;
my @path_info = split m{/}, $script_uri;

In his words:

Basically what was wrong was the way Blosxom was reading the URL. path_info() wasn't filled the way it is normally filled when CGI Wrap isn't used. But using QUERY_STRING doesn't completely solve the problem because it only will contain information when a question mark is used, and so many plugins will break etc.

I used SCRIPT_URI instead of SCRIPT_URL so I could make use of the $url variable in Blosxom. This means you should fill this variable, not depend on Blosxom to guess it. Also, if you call the script from a SSI anywhere else then you'll need to hard code a way to remove the this additional URL.

Hopefully this helps others out there. Remember, if you can't get Blosxom to run on your hosted site, check with the host's admins and see if they are using CGIWrap.