httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: [apreq-2] test tarball
Date Fri, 31 Oct 2003 05:30:53 GMT
Quoting Joe Schaefer <joe+gmane@sunstarsys.com>:

> 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 :-/.

OK, that sounds neat. So, I'm just stuck in the past, which is easily fixable.

> 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.

Yep, I have that in httpd.conf. But if I don't have to have it, that's even
better. Less chance for users of my module to screw up.

> 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.

> 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
> hours. 
> ----------------------------
> 
> It shouldn't be difficult to fix once we incorporate the new 
> test.

Thanks. I'll change the calls in my module in the meantime and I'll report back
if that did it.

-- 
Bojan

Mime
View raw message