httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <sor...@gmail.com>
Subject Re: Question on sub requests and output filter context.
Date Sun, 18 Sep 2011 10:34:10 GMT
On Thu, Sep 15, 2011 at 12:52, Martin Townsend
<martin.townsend@power-oasis.com> wrote:
> Hi,
>
> I have an output filter that parses custom tags to retrieve data from an
> application running on the same device.
>
> Everything was working well until I tried to move some HTML into Server Side
> Include pages.  Snippet below:
>
> <?smu smu extio_sensor_read mappings ?>
> <?smu smu extio_read front_ana all led ?>
> <?smu smu extio_read rear_ana all led ?>
>
> <!--#include virtual="/include/SSI_SensorStatus.html" -->
> <!--#include virtual="/include/SSI_SensorStatusAnalogRear.html" -->
>
> The first three commands will populate hash tables that are saved in my
> output filters context.
> The HTML in the included pages then use custom tags to query the hash tables
> but for some reason the hash tables are NULL.
>
> Having stepped through with the debugger I can see that the pointer to the
> output filter when processing the main HTML page is different to the one
> when parsing custom tags in SSI pages.  Looking through mod_include I can
> see it creates a sub request for include and sub requests call
> make_sub_request to create a new filter.  Should this new filter also
> inherit the output filters context?  Am I doing something wrong with my use
> of mod_include?  I've tried moving my filter so it's after mod_include but
> still the same problem.
>
> I'm using Server version: Apache/2.2.19 (Unix) on an  ARM board.
>
> Best Regards,
> Martin.
>
>

How do you construct the context of your filter? At the first
invokation of the filter or in the init function of the filter?

In the second case, it could be that you construct the context twice,
the first time in the main request processing and the second time in
the subrequest processing.

In my opinion, apache uses the same filter structure in both the main
and the sub request. In mod_includes apache creates a subrequest,
passing f->next to it. Thus, the first filter in the filter chain of
the subrequest is the filter succeeding the INCLUDES filter. In my
opinion, if you place your filter before the INCLUDES filter, your
filter should not be called in the subrequest if yours is a
AP_FTYPE_RESOURCE filter. If you place your filter after the INCLUDES
filter, the hash tables you mention are not initialised at the time
when your filter processes the responses of the includes subrequests.
I am not sure of what I'm saying because I have no experience in how
mod_includes interacts with other filters. Anyway, I hope this helps.

Have a look in server/request.c at make_sub_request. The subrequest
inherits the protocol filters of the main request, but not all of the
non-protocol output filters of the main request. Maybe you should make
your filter a AP_FTYPE_PROTOCOL filter such that it is not removed
from the chain by mod_includes.

S

Mime
View raw message