httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [apreq-2] test tarball
Date Fri, 31 Oct 2003 01:59:51 GMT
Bojan Smojver <> writes:

> It's been a while since I downloaded libapreq2, so maybe I'm just
> doing something wrong...

Ugh- I was trying to get away from having "constructors" like apreq_request()
called from mod_apreq (mainly because it made internal redirect support
easier).  Unfortunately I suppose it also means you can't currently use
httpd's filter API to insert the apreq_filter- your code would need to let
the constructor apreq_request() do it :-/.

> I'm testing this on Fedora Core 1, Test 3 and Apache 2.0.48, compiled
> from source. 
> First a bit of background to the problem. I use mod_apreq from within my
> handler, which is, of course, an Apache 2 module. In order to exercise input
> filters, I do this from within my handler:
> --------------------------------------------
> while((status=ap_get_brigade(r->input_filters,brigade,
>                              AP_MODE_READBYTES,APR_BLOCK_READ,
>                              HUGE_STRING_LEN))
>        !=APR_SUCCESS);
>   ;/* nothing */
> --------------------------------------------

Looks fine.  So how is the apreq filter getting involved in the request- 
do you have "AddInputFilter apreq" in your server config or something?
You don't need to do that for content handlers- the filter should load
itself automatically so long as you call apreq_request() before reading
from r->input_filters.

Whatever it is you're doing, I'd like to see a test added to env/t
that causes the segfault, so when it's fixed we can maintain support
for that approach.


> Meaning, for some reason req pushed into this function call is
> null. As far as I can see, req is obtain like this (line 365 in the
> same file): 
> --------------------------------------------
>     req = get_cfg(r)->req;
> --------------------------------------------
> I'm not sure if I'm doing something really stupid (this whole thing
> used to work with and older version of mod_apreq from CVS) or is this
> something that somebody else observed as well?

Correct- IIRC the culprit is likely this commit to env/mod_apreq.c:

revision 1.32
date: 2003/10/23 19:07:29;  author: joes;  state: Exp;  lines: +10 -21
Drop some debugging logs, and do a bit more refactoring (cut down on the
internal apreq_env* calls, some of which - especially
apreq_env_request() - had unintended side-effects). Also bump
apreq_env_magic_number to reflect the bugfixes made over the last 24

It shouldn't be difficult to fix once we incorporate the new 

Joe Schaefer

View raw message