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: Apache C++ equivalent of javax.servlet.Filter
Date Wed, 01 May 2013 12:23:23 GMT
On 2013-05-01 12:21, Sindhi Sindhi wrote:
> Hi,
>
> I'm developing a C++ module for Apache(httpd.exe) server. This C++ module
> intends to function the same as a Java module that we earlier developed for
> Tomcat. I'll be very thankful to you if you could answer the following
> queries I have about finding the Apache(httpd.exe server) C++ equivalents
> for the below Java classes.
>
> This Java code has references to the following -
>
> 1. javax.servlet.Filter
> In Java we have a class CustomFilter that implements javax.servlet.Filter.
> This CustomFilter class has an init() method that will be called when
> Tomcat starts. How can I achieve this for Apache(httpd.exe server)? means,
> how can I make a function call when Apache(httpd.exe server) starts.

There are three possibilities:

1. the pre_config hook. This is invoked before apache parses its 
configuration. I think this is not what you want.

2. the post_config hook. This is invoked after apache parses its 
configuration but before the children processes are invoked. This could 
be what you want.

pre_config and post_config are called twice when apache starts and each 
time the configuration is reloaded.

pre_config and post_config are called in the apache parent process with 
the privileges of the apache parent process.

3. the child_init hook. This is invoked whenever apache creates a new 
child process. This is invoked with the privileges of the apache 
children processes.

That was the answer to your question. However, in apache filters are 
typically initialised differently. Each filter may have an init 
function. If the filter has such an init function (i.e. if it's not 
null), then the init filter function is invoked automatically by apache 
after the fixups callback and before the handler callback. So the init 
function, if it exists, is invoked once per request.

> 2. javax.servlet.FilterConfig
> The above mentioned init() method takes in an argument of type
> FilterConfig. What is the Apache C++ equivalent of FilterConfig?

The ap_filter_t structure has a void pointer field called ctx. This is 
null by default. You can make it point to whatever object you want. You 
can initialise this ctx in the init function of the filter or when the 
filter is invoked for the first time. (Please note that a filter may be 
invoked several times for the same request, so you'll have to take care 
to distinguish between the several invocations for the same request and 
between the invocations triggered by different requests.)

I'm not sure what's the role of the FilterConfig object in Java 
servlets. Maybe you need a configuration object of your apache module 
and not a filter context. A filter context serves mainly to store a 
state between consecutive invocations of the filter for the same 
request. So the data in the filter context, as it is a state, changes. 
It's not really a configuration, which is more a read-only object.

> 3. The interface javax.servlet.Filter also has the method
> doFilter(ServletRequest request, ServletResponse response, FilterChain
> chain). In Apache C++ I can get the filter chain using the structure
> ap_filter_t. But how will I get the objects of
> ServletRequest/HttpServletRequest and ServletResponse/HttpServletResponse
> in C++ module? Means what are the corresponding structures I can access in
> Apache C++ module.
>
> The main filter callback function in my C++ module looks like this -
>
> EXTERN_C_FUNC apr_status_t filterOutFilter (
> 	ap_filter_t *filterChain,
> 	apr_bucket_brigade *inBucketList)
>

The request_rec *r field of the ap_filter_t structure plays the role of 
the ServletRequest.

The ap_filter_t *next field of the ap_filter_t structure plays the role 
of the FilterChain.

There is no ServletResponse object. Your filter gets this "bucket 
brigade" which is basically a linked list of "buckets". The buckets 
contain data coming from the upstream filters or from the handler.

So a typical filter would parse the bucket brigade (i.e. traverse the 
linked list of buckets and process the data they contain) and generate a 
new, filtered (transformed) bucket brigade. Then it would pass it to 
downstream filters.

Something like

for (all buckets in input brigade) {
    read data in bucket
    transform the data, optionally using
        the state stored in f->ctx
    optionally update the state in f->ctx
    append the transformed data to the output brigade
    if (we reached the end-of-stream)
       // if upstream filters were well-behaved
       // this would be the last invocation of the filter
       // for this request
       return ap_pass_brigade(f->next, output_brigade)
}
// we parsed the whole brigade without reaching
// to the end-of-stream => the filter will be invoked again
// later with the next part of the data coming from upstream
// filters
return ap_pass_brigade(f->next, output_brigade);

Note, as I said previously, that the filter may be called several times 
for the same request.

After passing a brigade containing an EOS (end-of-stream) bucket to a 
downstream filter well-behaved filters do not invoke ap_pass_brigade 
anymore. So, if all filters were well-behaved, no filter would be 
invoked after it got an EOS bucket. However, not all filters are 
well-behaved, so you must write your filter such that is behaves 
correctly even if upstream filters do not behave correctly. I.e. you 
have to be able to handle the case in which your filter is invoked again 
although you've encountered an EOS bucket in a previous invocation of 
your filter.

Regards,
Sorin

Mime
View raw message