Perl Archive::Tar Method Inexplicably Failing When Script Called in Internet Explorer

wwarby
wwarby used Ask the Experts™
on
I am moving a perl script from a Sun server to a Redhat server and have come across a very strange problem. My knowledge of UNIX/Linux/Perl is quite poor but we have nobody with more knowledge of Perl than me.

The script reads and displays the contents of archive files in the .taz format. It is a three stage process - you select a .taz file from a list which the Perl script reads from a directory, it then shows a list of files in the selected .taz file and finally shows the contents of the selected file from inside the archive.

When accessed from Firefox, Safari or Chrome, the script behaves exactly as expected. When access from Opera or Internet Explorer (tried 6 and 8), it fails to list the contents of the selected .taz file. By reading the error_log file we have traced the problem to a specific line of source code in the Perl script - see attached code.

It appears that calling the list_archive method of the Archive::Tar module is failing. I have tried outputting the $archive path to the screen to ensure that it is identical in both Firefox and IE, and it is. I have no idea where to go next, as this error doesn't seem like it should be possible. The error simply does not occur when used with Firefox which makes no sense as the server should be doing exactly the same thing regardless of the browser calling the Perl script. Any help much appreciated.
Line 51: # Pick up the list of reports currently held in the archive
Line 52: $tar = Archive::Tar->new();
Line 53: @files = $tar->list_archive( $archive ) ;
 
Error log:
 
[Tue Oct 20 14:55:58 2009] [error] [client 10.128.19.248] Could not create filehandle for '/work/archive/reports_combined/adtemp.taz, referer: http://revcap2/cgi-bin/wf_combined_ibarrs.pl 
[Tue Oct 20 14:55:58 2009] [error] [client 10.128.19.248] ': No such file or directory! at /work/wf_apache/cgi-bin/wf_combined_ibarrs.pl line 53, referer: http://revcap2/cgi-bin/wf_combined_ibarrs.pl 
[Tue Oct 20 14:55:58 2009] [error] [client 10.128.19.248] No data could be read from file at /work/wf_apache/cgi-bin/wf_combined_ibarrs.pl line 53, referer: http://revcap2/cgi-bin/wf_combined_ibarrs.pl

Open in new window

Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
are you sure $archive is the same in both cases? when you print it out, are you printing something like:

print "my archive '$archive'\n";

Author

Commented:
I just used "print $archive;"

I've just looked at the HTML source code very carefully and although the paths are identical, in the output on Firefox the path has no whitepace after it - the next text after the end of the path is a <p>, all on the same line. In the output on IE, there appears to be a carriage return after the path. Do you think perhaps Internet Explorer is sending a rogue carriage return as part of the value of "$archive"? ($archive is ultimately derived from the POST query parameter "archive", which is from a <select> list in the HTML generated by an earlier stage in the Perl script).

I guess the simple way to test that is to hack out any possible carriage returns with a regex before using the $archive variable. Any chance you know how to do that in Perl? In PHP it'd be something like:

$archive = preg_replace($archive, '/[\n\r]*/g', '');

...but Perl as I say, is not my strong suit.
Commented:
$archive =~ s/\r|\n//g;

Author

Commented:
Well how about that? Whatever version of Perl was on our Sun servers, it forgave that mistake in the original source code where the version on our new Redhat servers doesn't. That's fixed the problem, thanks a lot for your help!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial