More CGIHandler problems

Dave Rolsky <[email protected]>
Newsgroups gmane.comp.web.mason.devel
Message-ID <[email protected]>
So simply rethrowing _all_ exceptions in the exec() method isn't quite
right.  We want to catch abort exceptions and send the output normally.
Unlike ApacheHandler, we don't want to try to catch decline exceptions,
since there's nothing we can do with them.

Why?  Because CGIHandler doesn't return the value of exec() back to the
caller.  I could try to add that, but I really don't want to make even
more potentially buggy changes to this code.

Unfortunately, this means that decline exceptions cause Mason to give an
error.  Why?  Because a decline gets turned into a TopLevelNotFound
exception.  ApacheHandler handles these specially by returning a 404.
CGIHandler doesn't do this, and I don't even think we can, since CGI
doesn't hook into the web server in the same way mod_perl does.

So here's what I'm proposing:

- Modify CGIHandler to handle abort exceptions specially.  If $m->abort()
  or $m->abort(200) are called, we will send send headers if they haven't
  yet been sent.

- Don't handle decline or TopLevelNotFound specially.  This will make for
  nasty ugly errors, but there's not much to be done about this with the
  current architecture.

- All other exceptions just get rethrown.

- CGIHandler does not, and will not (in stable) return the value of
  Request->exec to the caller of any of it's handle_* methods.  This
  differs from ApacheHandler, which returns this value to the caller of
  handle_request().


In dev, I want to try to make the behaviors as similar as possible, but
that's the future.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.