Re: CGI::Carp sometimes fails
by afoken (Chancellor) on May 18, 2024 at 20:26 UTC
|
I just get a 500 error from the browser.
So, what's in your webserver's error log? That's where all CGI errors will end, no matter if you use CGI::Carp or not.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
Grrrr...
** kicks self **
Having spent so long using shared hosting with very little access to logs, I forget they exist!
what's in your webserver's error log?
ModSecurity: Output filter: Response body too large (over limit of 1048576, total not specified)
OK - that makes sense...the JPEG image that it's trying to serve is going to be relatively big.
| [reply] [d/l] |
|
| [reply] |
|
|
over limit of 1048576, total not specified
That a strangely vague message in the context of HTTP. I'm assuming that pseudo security module is talking about a missing "Content-Length" header? (Also, 1 MB is quite tiny in modern web usage. Most minimized JavaScript libraries are larger these days...)
In your case, i'd look into the error handling module and check if it fails to generate the appropriate headers. Also, i'd look into coercing it to set the content type to something like 'application/octet-stream' if it detects binary data (e.g. if any byte > 127).
And, since its Perl we are talking here, bytes with a value greater than 255 also exist, which might or might not mess up other things as well. You might want to check if your $file variable gets real BINARY data or if there's an UTF8 decoder between you and the file on disk.
| [reply] |
|
Re: CGI::Carp sometimes fails
by eyepopslikeamosquito (Archbishop) on May 19, 2024 at 00:51 UTC
|
| [reply] [d/l] |
|
Note that use v5.36; disables this ancient Perl-4-style multidimensional array emulation
Thanks for the heads up eyepopslikeamosquito :)
Now that I know where to store modules thanks to haj, it's my intention to rewrite this legacy code and remove the current repetition. Looks like I might have to move that up the todo list...certainly before I upgrade to Perl v5.36.
| [reply] |
Re: CGI::Carp sometimes fails
by Danny (Chaplain) on May 18, 2024 at 16:43 UTC
|
print "$file{'receipt', 'file'}\n"
or
use Data::Dumper;
print Dumper($file{'receipt', 'file'})
give? | [reply] [d/l] [select] |
|
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
use strict;
use warnings;
use lib ( "$ENV{'DOCUMENT_ROOT'}/../lib", "$ENV{'DOCUMENT_ROOT'}/../..
+/prod/lib" );
use Bod::CRM;
use Site::Utils;
use Data::Dumper;
print "Content-type: text/plain\n\n";
print Dumper $file{'receipt', 'file'};
exit;
This gives me a 500 error which is not picked up by CGI::Carp
But - I've tried printing out to a file and $file{'receipt', 'file'} contains the contents of a JPEG image file. Can die and print not handle some encoded characters such as those in an image file?
I am trying to debug some code that handles file uploads from a webpage and came across this strange behaviour of die working in some places and not others. So I created a simple example to demonstrate it. But it seems it's an encoding issue that is something I am getting everywhere from .htaccess files to blog editing since moving servers 😒 | [reply] [d/l] [select] |
|
contains the contents of a JPEG image file.
I suppose one approach to try and narrow it down would be divide and conquer the contents of $file{'receipt', 'file'}. Split it in half and check both halves. Split the bad half again, etc.
You said you tried printing the contents to a file. I assume that was successful?
EDIT: Or instead of divide and conquer maybe try something like:
my $len = length $str;
for(my $i = 1; $i <= $len; $i++) {
print substr($str, 0, $i)
}
| [reply] [d/l] |
|
| [reply] |
Re: CGI::Carp sometimes fails
by Anonymous Monk on May 18, 2024 at 19:48 UTC
|
I've never even used this module without also enabling warnings, maybe you need to see them too:
use CGI::Carp qw/fatalsToBrowser warningsToBrowser/;
Also consider rolling your own die handler at
DOING MORE THAN PRINTING A MESSAGE IN THE EVENT OF PERL ERRORS | [reply] [d/l] |