You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Martin Townsend <ma...@power-oasis.com> on 2010/08/18 14:24:39 UTC
Problem with ap_internal_redirect_handler
Hi,
I'm currently trying to add the ability to redirect requests for the
initial html page to a captcha page when there is no session or no valid
session. Currently I'm doing this in the fixups hook:
mod_smu_fixups(request_rec* r) {
const char * content_type_str_p;
const char * content_len_str_p;
/* Get the modules config vector. */
MOD_SMU_SERVER_CFG_T * const smu_svr_cfg_p = ap_get_module_config(
r->server->module_config,
&smu_module);
if(DEBUG_ENABLED & DEBUG_SMU) {
ap_log_rerror(APLOG_MARK, APLOG_NOTICE, 0, r,
"SMU Module Fixups %s (%s)",
r->method, r->filename);
ap_log_rerror(APLOG_MARK, APLOG_NOTICE, 0, r,
"SMU Module Fixups init-req(%d) handler(%s)
content-type(%s)",
ap_is_initial_req(r), r->handler, r->content_type);
}
/*
* If we are being requested for the captcha image then send this
request
* to the smu-captcha content generator which will generate it on
the fly.
*/
if(smu_captcha_is_image_request(r)) {
ap_log_rerror(APLOG_MARK, APLOG_NOTICE, 0, r,
"SMU Fixup CAPTCHA Image (%s)", r->filename);
r->handler = "application/smu-captcha";
return OK;
}
/* If this is the initial request (ie not a sub request) clear the
error
* and command list */
if(ap_is_initial_req(r)) {
/* First up ensure that the error and command list are empty */
mod_smu_list_empty(smu_svr_cfg_p->command_list_p);
/* Empty error list */
mod_smu_list_empty(smu_svr_cfg_p->error_list_p);
/* Check to see if a captcha page is needed. */
if(captcha_display_needed(r)
&& apr_strnatcasecmp(r->content_type, "text/html") == 0
) {
//r->handler = "application/smu_captcha";
//ap_internal_redirect("/captcha.shtml", r);
ap_log_rerror(APLOG_MARK, APLOG_NOTICE, 0, r,
"SMU Fixup CAPTCHA needed (%s)", r->filename);
ap_internal_redirect_handler("/captcha.shtml", r);
return OK;
}
}
....
}
So if we have an initial request that is HTML then redirect to
captcha.shtml which contains SSI for header, footer etc. There will
also be a request for a captcha image using a fixed filename. The fixup
will detect this and send the request to a custom handler that will
auto-generate the captcha image. The problem I have is that I'm getting
sub-requests and requests for the captcha image twice, see log below. I
assume that the original request for index.shtml and the request for
captcha.shtml are being processed. Using firebug I see that the captcha
image that is displayed in the debug output isn't the one that gets
displayed in the HTML so I can assume that the image is being sent
twice. I notice that the browser goes into a waiting state until the
timeout expires. Does anybody know what I'm doing wrong? I've tried
returning DECLINED or DONE after the ap_internal_redirect_handler call
but still get the problem. Any help appreciated.
Best Regards,
Martin.
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Fixup
CAPTCHA needed (/var/www/index.shtml), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/captcha.shtml), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageHead.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageTop.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_Contents.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageFooter.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageHead.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageTop.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_Contents.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/include/SSI_PageFooter.html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(0) handler((null)) content-type(text/html), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/sscd.css), referer: http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(1) handler((null)) content-type(text/css), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/captcha_image.gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(1) handler((null)) content-type(image/gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] SMU Fixup
CAPTCHA Image (/var/www/captcha_image.gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:41 2010] [notice] [client 192.168.1.70] smu-captcha
/var/www/captcha_image.gif, referer: http://192.168.0.52/index.shtml
[Wed Aug 18 12:39:44 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/captcha_image.gif)
[Wed Aug 18 12:39:44 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(1) handler((null)) content-type(image/gif)
[Wed Aug 18 12:39:44 2010] [notice] [client 192.168.1.70] SMU Fixup
CAPTCHA Image (/var/www/captcha_image.gif)
[Wed Aug 18 12:39:44 2010] [notice] [client 192.168.1.70] smu-captcha
/var/www/captcha_image.gif
Re: Problem with ap_internal_redirect_handler
Posted by Martin Townsend <ma...@power-oasis.com>.
On 18/08/2010 13:54, Sorin Manolache wrote:
> if (!ap_is_initial_req(req))
> return DECLINED;
Thanks for the tip. This stops the SSI include sub requests but not the
two requests for the captcha image they are both initial requests.
[Wed Aug 18 14:03:25 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/captcha_image.gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 14:03:25 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(1) handler((null)) content-type(image/gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 14:03:25 2010] [notice] [client 192.168.1.70] SMU Fixup
CAPTCHA Image (/var/www/captcha_image.gif), referer:
http://192.168.0.52/index.shtml
[Wed Aug 18 14:03:25 2010] [notice] [client 192.168.1.70] smu-captcha
/var/www/captcha_image.gif, referer: http://192.168.0.52/index.shtml
[Wed Aug 18 14:03:28 2010] [notice] [client 192.168.1.70] SMU Module
Fixups GET (/var/www/captcha_image.gif)
[Wed Aug 18 14:03:28 2010] [notice] [client 192.168.1.70] SMU Module
Fixups init-req(1) handler((null)) content-type(image/gif)
[Wed Aug 18 14:03:28 2010] [notice] [client 192.168.1.70] SMU Fixup
CAPTCHA Image (/var/www/captcha_image.gif)
[Wed Aug 18 14:03:28 2010] [notice] [client 192.168.1.70] smu-captcha
/var/www/captcha_image.gif
I see that mod_rewrite just changes the requests filename, I tried the
same but never received the full content of captcha.shtml.
Regards,
Martin.
--
Martin Townsend
power*oasis*
Suite 1, Unit 41
Shrivenham Hundred Business Park
Majors Road
Watchfield
Swindon
Wilts SN6 8TZ
Re: Problem with ap_internal_redirect_handler
Posted by Ben Noordhuis <in...@bnoordhuis.nl>.
On Tue, Aug 24, 2010 at 14:56, Ray Morris <su...@bettercgi.com> wrote:
> This sounds to me like an access_checker, which should be
> called from the access_checker hook. Filters, as I understand
> it, are for transforming the content - compressing it, for example.
> Entirely replacing the content with an unrelated document sounds
> like an abuse of filters. I wonder if this might be a case of
> "if all you have is a hammer ..."
Agreed, but I don't think the request body is available when the
access_checker hook is run (the OP mentioned he needed to extract POST
data).
Re: Problem with ap_internal_redirect_handler
Posted by Martin Townsend <ma...@power-oasis.com>.
On 24/08/2010 11:19, Ben Noordhuis wrote:
> On Tue, Aug 24, 2010 at 11:50, Martin Townsend
> <ma...@power-oasis.com> wrote:
>> Do you mean setting a request note from the input filter that an output
>> filter picks up which can then output the captcha.shtml?
> Yes, if your module consists of filters only. If it also includes a
> content generator, I'd probably do it from there. But you know your
> code best so pick the most appropriate solution.
I don't have a content generator. Can I call
ap_internal_redirect_handler to perform the redirect from my output
filter or do I have to destroy the original bucket brigade and load the
contents of captcha.shtml into a new one (in which case how do I ensure
that the SSI output filter is called as captcha.shtml contains SSI). If
I can call ap_internal_redirect_handler how do I stop the original
request from generating a response after ap_internal_redirect_handler
returns?
Best Regards,
Martin.
Re: Problem with ap_internal_redirect_handler
Posted by Ben Noordhuis <in...@bnoordhuis.nl>.
On Tue, Aug 24, 2010 at 11:50, Martin Townsend
<ma...@power-oasis.com> wrote:
> Do you mean setting a request note from the input filter that an output
> filter picks up which can then output the captcha.shtml?
Yes, if your module consists of filters only. If it also includes a
content generator, I'd probably do it from there. But you know your
code best so pick the most appropriate solution.
Re: Problem with ap_internal_redirect_handler
Posted by Martin Townsend <ma...@power-oasis.com>.
On 24/08/2010 10:24, Ben Noordhuis wrote:
> On Tue, Aug 24, 2010 at 11:11, Martin Townsend
> <ma...@power-oasis.com> wrote:
>> I'm trying to add a captcha feature to our custom module. How should I
>> handle the returned captcha code in the POST data. I currently have an
>> input filter for processing other POST data but if I use this how do I
>> redirect to the captcha.shtml page if validation fails. If I validate the
>> code in an earlier phase like the fixups how do I read the POST data? Does
>> anyone know the best way to handle this. I'm using v2.2-3.
> Martin, can't your filter set a request note that one of your hooks
> further down the line picks up?
Hi Ben,
Do you mean setting a request note from the input filter that an output
filter picks up which can then output the captcha.shtml?
Regards,
Martin.
Re: Problem with ap_internal_redirect_handler
Posted by Ben Noordhuis <in...@bnoordhuis.nl>.
On Tue, Aug 24, 2010 at 11:11, Martin Townsend
<ma...@power-oasis.com> wrote:
> I'm trying to add a captcha feature to our custom module. How should I
> handle the returned captcha code in the POST data. I currently have an
> input filter for processing other POST data but if I use this how do I
> redirect to the captcha.shtml page if validation fails. If I validate the
> code in an earlier phase like the fixups how do I read the POST data? Does
> anyone know the best way to handle this. I'm using v2.2-3.
Martin, can't your filter set a request note that one of your hooks
further down the line picks up?
Re: Problem with ap_internal_redirect_handler
Posted by Martin Townsend <ma...@power-oasis.com>.
Hi,
I'm trying to add a captcha feature to our custom module. How should I
handle the returned captcha code in the POST data. I currently have an
input filter for processing other POST data but if I use this how do I
redirect to the captcha.shtml page if validation fails. If I validate
the code in an earlier phase like the fixups how do I read the POST
data? Does anyone know the best way to handle this. I'm using v2.2-3.
Many Thanks,
Martin.
Martin Townsend
power*oasis*
Suite 1, Unit 41
Shrivenham Hundred Business Park
Majors Road
Watchfield
Swindon
Wilts SN6 8TZ
Re: Problem with ap_internal_redirect_handler
Posted by Martin Townsend <ma...@power-oasis.com>.
On 18/08/2010 13:54, Sorin Manolache wrote:
> On Wed, Aug 18, 2010 at 14:24, Martin Townsend
> <ma...@power-oasis.com> wrote:
>> Hi,
>>
>> I'm currently trying to add the ability to redirect requests for the initial
>> html page to a captcha page when there is no session or no valid session.
>> Currently I'm doing this in the fixups hook:
>>
>> mod_smu_fixups(request_rec* r) {
>> ....
>> }
>>
>> So if we have an initial request that is HTML then redirect to captcha.shtml
>> which contains SSI for header, footer etc. There will also be a request for
>> a captcha image using a fixed filename. The fixup will detect this and send
>> the request to a custom handler that will auto-generate the captcha image.
>> The problem I have is that I'm getting sub-requests and requests for the
>> captcha image twice, see log below. I assume that the original request for
>> index.shtml and the request for captcha.shtml are being processed. Using
>> firebug I see that the captcha image that is displayed in the debug output
>> isn't the one that gets displayed in the HTML so I can assume that the image
>> is being sent twice. I notice that the browser goes into a waiting state
>> until the timeout expires. Does anybody know what I'm doing wrong? I've
>> tried returning DECLINED or DONE after the ap_internal_redirect_handler call
>> but still get the problem. Any help appreciated.
>>
>> Best Regards,
>> Martin.
> Try putting
>
> if (!ap_is_initial_req(req))
> return DECLINED;
>
> at the beginning of your fixups callback.
>
> Sorin
I've Just got to the bottom of why I am receiving the captcha image
request twice. I had firebug turned on which was requesting the image
again although it didn't for all the other images on the page.
--
Martin Townsend
power*oasis*
Suite 1, Unit 41
Shrivenham Hundred Business Park
Majors Road
Watchfield
Swindon
Wilts SN6 8TZ
Re: Problem with ap_internal_redirect_handler
Posted by Sorin Manolache <so...@gmail.com>.
On Wed, Aug 18, 2010 at 14:24, Martin Townsend
<ma...@power-oasis.com> wrote:
>
> Hi,
>
> I'm currently trying to add the ability to redirect requests for the initial
> html page to a captcha page when there is no session or no valid session.
> Currently I'm doing this in the fixups hook:
>
> mod_smu_fixups(request_rec* r) {
> ....
> }
>
> So if we have an initial request that is HTML then redirect to captcha.shtml
> which contains SSI for header, footer etc. There will also be a request for
> a captcha image using a fixed filename. The fixup will detect this and send
> the request to a custom handler that will auto-generate the captcha image.
> The problem I have is that I'm getting sub-requests and requests for the
> captcha image twice, see log below. I assume that the original request for
> index.shtml and the request for captcha.shtml are being processed. Using
> firebug I see that the captcha image that is displayed in the debug output
> isn't the one that gets displayed in the HTML so I can assume that the image
> is being sent twice. I notice that the browser goes into a waiting state
> until the timeout expires. Does anybody know what I'm doing wrong? I've
> tried returning DECLINED or DONE after the ap_internal_redirect_handler call
> but still get the problem. Any help appreciated.
>
> Best Regards,
> Martin.
Try putting
if (!ap_is_initial_req(req))
return DECLINED;
at the beginning of your fixups callback.
Sorin