List Info

Thread: Re: * Disabled Bric::App::PreviewHandler::uri_handler` under mod_perl




Re: * Disabled Bric::App::PreviewHandler::uri_handler` under mod_perl
user name
2008-04-23 03:35:47
On Tue, 22 Apr 2008, theorybricolage.cc wrote:
> * Disabled Bric::App::PreviewHandler::uri_handler`
under mod_perl 2 for now.
>  It really seems to fuck things up, and the only thing
it does is allow files
>  requested by preview pages to be loaded properly. I
will figure out how to
>  get that working again, but I'll need some help. In
the meantime, it makes a
>  whole bunch of other problems go away. It's bizarre.

I don't really have any useful information,
but I think it's related to the changes in apache2/modperl2
handlers. You have to be more careful with what is returned
from handlers (c.f. the HTTP_OK thing), and the config is
reloaded after it checks that it loads okay the first
time..


> +++ bricolage/branches/dev_apache2/conf/httpd.conf ...
>  -99,6 +99,7 
>   PerlModule Apache2::RequestIO
>   PerlModule Apache2::ServerUtil
>   PerlModule Apache2::SubRequest
> +  PerlModule Apache2::Upload

This is another thing that is a ballbreaker,
having to manually load everything
(or rather knowing what all to load).

Re: * Disabled Bric::App::PreviewHandler::uri_handler` under mod_perl
user name
2008-04-23 11:59:52
On Apr 23, 2008, at 01:35, Scott Lanning wrote:

> On Tue, 22 Apr 2008, theorybricolage.cc wrote:
>> * Disabled Bric::App::PreviewHandler::uri_handler`
under mod_perl 2  
>> for now.
>> It really seems to fuck things up, and the only
thing it does is  
>> allow files
>> requested by preview pages to be loaded properly. I
will figure out  
>> how to
>> get that working again, but I'll need some help. In
the meantime,  
>> it makes a
>> whole bunch of other problems go away. It's
bizarre.
>
> I don't really have any useful information,
> but I think it's related to the changes in
apache2/modperl2
> handlers. You have to be more careful with what is
returned
> from handlers (c.f. the HTTP_OK thing), and the config
is
> reloaded after it checks that it loads okay the first
time..

The docs are pretty clear that DECLINED is what a
TransHandler should  
return, to allow Apache's internal translation handler to
run. It does  
seem to do that, but oddly, there is an interim request. For
example,  
if I click the Edit desk link, it requests
/workflow/profile/desk/ 
101/101, the TransHandler processes it, then the
AccessHandler, and  
then, before the ResponseHandler runs, there's a new
request, for / 
101/, that the TransHandler and AccessHandler handle. I've
no idea  
where this comes from. Under Apache 1, we next have the  
ResponseHandler process the original URL, and then the
CleanupHandler  
runs, disconnecting the session hash. Under Apache 2, The  
CleanupHandler runs before the ResponseHandler, which is
just bizarre.  
Then there is no session during the ResponseHandler, thus
the errors.

If I disable the TransHandler (PreviewHandler::uri_handler),
then  
there is no interrim request for /101/ and everything just
works. If I  
put in the TransHandler, even if uri_handler does nothing
more than  
return DECLINED, I get the weird interim request and the
cleanup  
before the response. This is completely mystifying to me.

I'll post to the mod_perl list about this today.

> This is another thing that is a ballbreaker,
> having to manually load everything
> (or rather knowing what all to load).

I think you pretty much got them all. But it *would* be nice
if there  
was a way to just say "Load them all!" Odd that it
doesn't handle this  
for you for Apache2::Upload, as it's clearly a dependency
that $r- 
 >upload has.

Thanks for your notes, Scott. Other than the TransHandler
issue, I  
think it's nearly done. Although we'll see how things go
once I enable  
SSL.

Best,

David

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )