Craig Shelley wrote:
Hello again..
On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote:
see Apache::SSI for mp1 - it does exactly what you are trying to do
and
is
subclassable, so you can add your own tags/functionality if you want.
That is exactly what I am already doing.
When using #exec
Hello again..
>
> On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote:
>
> see Apache::SSI for mp1 - it does exactly what you are trying to do
and
> is
> subclassable, so you can add your own tags/functionality if you want.
>
That is exactly what I am already doing.
When using #exec directive
Hello..
Just Forwarding this to the list
> Having no idea as to how the internals of modperl and apache actually
> work, this may seem like a bit of a dumb suggestion.
>
> When doing a subrequest from within a filter, the most ideal situation
> would be to have access to the output from within t
Hi All,
On Wed, 2003-08-27 at 02:33, Geoffrey Young wrote:
> hi craig.
>
>before we continue, please try the latest cvs (without the patch I sent)
> and see if your stuff segfaults there. if not, at least we know we've
> isolated the segfault and just have bad logic to fix :)
Well:
It s
Craig Shelley wrote:
MP_AP_PREFIX => /home/craig/temp/mod_perl-1.99_09/
hi craig.
before we continue, please try the latest cvs (without the patch I sent)
and see if your stuff segfaults there. if not, at least we know we've
isolated the segfault and just have bad logic to fix :)
if
Geoffrey Young wrote:
[...]
as I said, nowhere in any of the module shipped with core do I find
logic like this - mod_include and mod_cgi both seem to call
ap_run_sub_req without flushing the main data stream (though
mod_include does split the stream and send the data _prior to the tag_
off).
Geoffrey Young wrote:
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently
being operated on is explicity flushed. this is bad within a
(streaming) filter where you are expected to call $f->print yourself,
as the dat
however, removing that logic causes api/lookup_uri2.t to fail, but I
suspect this is an issue with puts() rather than the subrequest
mechanism - changing puts() to print() makes everything work just
fine. does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
Geoffrey Young wrote:
Stas Bekman wrote:
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report
as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with t
Craig Shelley wrote:
On Tue, 2003-08-26 at 19:03, Stas Bekman wrote:
Thanks, but you have missed the core dump's backtrace.
I am sorry but I have never used core files before, so forgive me if I
have done this all wrong.
No worries, this task is not trivial. Your trace is almost perfect. The only
Stas Bekman wrote:
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report
as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with that logic, what ends up h
On Tue, 2003-08-26 at 19:03, Stas Bekman wrote:
> Thanks, but you have missed the core dump's backtrace.
I am sorry but I have never used core files before, so forgive me if I
have done this all wrong.
I configured apache to only have one server process.
Then using gdb, I connected to the serve
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report as
explained http://perl.apache.org/bugs/. Please do so.
Here is that bug report related to the earlier postings.
-8<-- Start Bug Report 8<--
1. Problem Description:
> I'll take a look at it. But you didn't supply a complete bug report as
> explained http://perl.apache.org/bugs/. Please do so.
Hi,
Here is that bug report related to the earlier postings.
-8<-- Start Bug Report 8<--
1. Problem Description:
Craig Shelley wrote:
does anything change if you use
$rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
No it doesn't seem any different, the server still seg faults.
When it does this, it produces no output at all.
telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape char
> does anything change if you use
>
>$rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
No it doesn't seem any different, the server still seg faults.
When it does this, it produces no output at all.
telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'
my $rr = $f->r->lookup_uri("subrequest.txt");
#$rr->run;
For some reason, the server segfaults when the above code is run (with
the $rr->run line present)
does anything change if you use
$rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
?
--Geoff
--
Reporting bugs:
Hello,
I am a newbie to this list, so please forgive me if this is not the
place where I should asking this question.
I am writing a filter module for MP2 that will parse its input for
certain embedded commands.
One of these commands should cause the filter to issue a SubRequest to
get the output
18 matches
Mail list logo