Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of sindhi.for@gmail.com
 designates 209.85.223.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5181093B.7060006@gmail.com>
References: 
 <CANOjuGHTdYKyYhMZxNSo41HUdznnhBUjc_VenS4aQJkDJ=WMPQ@mail.gmail.com>
	<5181093B.7060006@gmail.com>
Date: Fri, 3 May 2013 13:19:00 +0530
Message-ID: 
 <CANOjuGFU0py87f99h0g-2vmsz_guTUPuDzmHn4ZVJCPm4-tG3Q@mail.gmail.com>
Subject: Re: Apache C++ equivalent of javax.servlet.Filter
From: Sindhi Sindhi <sindhi.for@gmail.com>
To: modules-dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=089e010d91568a534504dbcb95ef

--089e010d91568a534504dbcb95ef
Content-Type: text/plain; charset=ISO-8859-1

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 <sorinm@gmail.com> 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
>

--089e010d91568a534504dbcb95ef--