Ben,
I haven't looked at the code, and I have never looked at this, but
just as a thought, is there a sub-request created and executed during
processing? That is really what this sounds like. You can determine
this by looking at r->main to find the original request, which is
where the input_filter will always store data.
Ryan
On Mon, 7 Mar 2005 16:46:18 -0600, Ben Collins-Sussman
<sussman@collab.net> wrote:
> Hey Justin E. --
>
> This is a followup discussion to our code-in-progress to send all
> locktokens in the MERGE request body.
>
> I'm utterly surprised. The request_rec that your input filter stores
> the doc in turns out to be a *different* request_rec than is available
> to mod_dav_svn later on.
>
> I walked through gdb; the two request_rec structures have different
> addresses, as do their r->pools. Yet they both look like they're
> "MERGE" requests when I examine them.
>
> How is this possible? What the heck is going on?
>
> (That certainly explains why apr_pool_userdata_get() was returning
> NULL. It's a totally different r->pool! The table technique would
> fail as well.)
>
> I've attached my patch-in-progress for you to look at.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 8 01:59:05 2005