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
