httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sindhi Sindhi <>
Subject Re: Apache C++ equivalent of javax.servlet.Filter
Date Fri, 03 May 2013 07:53:00 GMT
I'm so sorry, I searched, and found that request_rec has the below members -
char *args;
char *unparsed_uri;
apr_uri_t parsed_uri;

Which of the below members will have the exact URI that is passed from
the browser?

On Fri, May 3, 2013 at 1:19 PM, Sindhi Sindhi <> wrote:

> Thankyou so much for the reply.
> I had another question, how can I get the query string in Apache?
> Something thats similar to getQueryString() of Java's HttpServletRequest.
> I have access to the below objects in my module -
> ap_filter_t *f
> request_rec *r = f->r;
> From the request_rec object how can I get the query string/URL ?
> Thanks again.
> On Wed, May 1, 2013 at 5:53 PM, Sorin Manolache <> wrote:
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message