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