You are viewing a plain text version of this content. The canonical link for it is here.

Posted to modperl@perl.apache.org by Mark Stosberg <ma...@summersault.com> on 2008/04/15 21:19:09 UTC

Best practices for returning 404/file-not-found pages inside and outside of mod_perl

It seems that using CGI, it is too late return a true 404 once the 
script is processing the request. It's possible to still send output 
that returns "page not found" text, but the HTTP status code will be 200.

More recently, I learned that with mod_perl, I learned that I can get
the system to return a true 404, so I updated my CGI::Application logic 
to do that when possible:

  if (exists $ENV{MOD_PERL}) {
    $self->header_add( -status => 404 );
    return '';
  }
  else {
     return $self->error(title => 'Page not found')
  }

However, I don't think I'm doing the ideal think in mod_perl, because it
behaves strangely in some cases. Two specific cases:

If I use GET on the command line, instead of 404, I'll get back this:
"500 EOF when chunk header expected"

Unless I fallback to HTTP 1.0:

PERL_LWP_USE_HTTP_10=1 GET ...

But for some reason, setting this environment variable was not working
for with Test::WWW::Mechanize.

More troubling is the behavior I see in the browser: The first time I
access the script that would through this 404 in mod_perl, it works.
Then for attempts 2 through 6 return internal server errors complaining
about "can't locate modules". Starting on load 7, the pages are returned
reliably with the 404 error. WTF?

( This is with Apache 1.3x and mod_perl 1.x )

The approach of CGI::Application::Dispatch is to also return the "404"
code, but also returns the body content along with it. In my case, I'm
hoping to trigger the internal ErrorDocument 404 page instead of
re-inventingt that wheel.

What am I missing?

Thanks!

    Mark

Re: Best practices for returning 404/file-not-found pages inside and outside of mod_perl

Posted by Graham TerMarsch <mo...@howlingfrog.com>.

On Thursday 01 May 2008 7:06 am, André Warnier wrote:
> Mark Stosberg wrote:
> >> +    my $dir = dirname(__FILE__);
> >> +    use lib $dir.'/../config';
> >> +    use lib $dir.'/../perllib';
> >
> > Actually, for some reason that syntax didn't work either, but this did
> > work on my modperl-startup.pl:
> >
> >  use lib dirname(__FILE__).'/../config';
> >  use lib dirname(__FILE__).'/../perllib';
> >
> >     Mark
>
> this is a question to the perl gurus here :
>
> In the first part above (what does not work), is it not because the "use
> lib" instructions are actually "executed" at the perl *compile* time, at
> which time the $dir variable does not have any value yet ?

Yes.

Crazier yet, if you do it as:

    my $dir;
    BEGIN { $dir=dirname(__FILE__) };
    use lib $dir.'/../config';
    use lib $dir.'/../perllib';

and put the assignment in a BEGIN block, it still doesn't work (at least, I 
haven't been able to get it to work).

I cheated, and when I needed this idiom I created a module that exported the 
value, and which assigned it in its "import()" method.  Gave me something 
like:

  use FindMe qw($ME);
  use lib $ME.'/../config';
  use lib $ME.'/../perllib';

and that worked fine.  The "import()" routine gets called and sets the value 
before its used in the following lines.

Now... why the BEGIN block doesn't do it, I've no idea and didn't poke too 
much farther into it to figure out why.

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.