httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: ErrorDocument's Behaviour
Date Tue, 18 May 2010 19:40:11 GMT
On Tue, 18 May 2010 15:13:11 -0300
André Manhaes Machado <andre.manhaes@gmail.com> wrote:

> Searching a way to bypass this issue, I took a look in the code in the
> function ap_process_request(I'm using apache 2.2.11):

> [chop]

> I did some debug in it and I saw that the requests that are send to weblogic
> come from with status access_status == OK when the page is not found.

That's the status the plugin returns.  It's taken charge of the request,
including sending you its own error response.

> I'm wondering what the reason for httpd wraps only errors which it do and
> requests from other "entities" are just hand over to the user.

httpd allows modules to take control and return OK, or to return an
error status and go into an errordocument path.  The BEA plugin (== module
in apache terminology) takes control.

It won't help with a third-party plugin (unless you're prepared to get your
hands dirty), but take a look at mod_proxy's ProxyErrorOverride.

> I believe it there should be a way to extend this behaviour to all requests
> incomes in apache.

The case we have here is where access_status is OK but r->status indicates
an error.  That indicates the server is effectively already in the 
errordocument path: the weblogic plugin has taken a shortcut!
If you try to change that, you're up against recursive errordocuments.
Having said that, I expect you could do something by adding a new
hook in the code you pasted, and hooking a function that'll
set access_status to r->status along with checks and housekeeping
that work with your plugin.

-- 
Nick Kew

Mime
View raw message