Re: [mp2] access to merged external (non-perl) config directives
> I know you can do:
> $r->location_merge('container_string');
> which forces an earlier merge, but I'm not sure it'll affect the conf
> tree shown by Apache::Directive. Have you tried looking at the C code to
> see whether there is a C API for that?
well, there's $r->per_dir_config and $r->request_config which return
an Apache::ConfVector object.
there's Apache::Directive::walk_config which takes an Apache::CmdParms
object (i have no idea from where, how one applies this, etc) and
an Apache::ConfVector object, presumably the one returned from
$r->(per_dir|request)_config. although, that seems like more of a
"write" than a "read" method. what i'm after is the result of the
merge without actually permanently modifying anything.
will look at httpd source i guess, and the mod_perl 2 source again.
.dorian
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] PerlModule vs PerlLoadModule
if PerlLoadModule supplants the command table, i surmise it does the job of PerlModule as well (which i understand to be roughly the equivalent of 'use'). i'm wondering, would there ever be a reason to load a module without wanting to supplant the command table with any existing values that may be present? would it make sense at all to effectively disambiguate the two directives by making them both synonyms for PerlLoadModule? cheers .dorian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
libapreq and filters
suppose i wanted to significantly alter the structure of a POST request via Apache::Request, but i wanted to re-inject the request body back into the input bucket brigade to be processed by a later module? i'm thinking something like this: POST from client Apache::Request-based handler consumes request body entirely "" creates document based on POSTdata "" changes request method to PUT "" inserts new document back into stream mod_put_takes document to be PUT and PUTs it somewhere is this kind of thing possible in any way? .dorian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] recirculating (sub)?request output
suppose i wanted to run a subrequest, but instead of outputting the body (or headers, or anything) of that request down the wire, i wanted to snag it for processing in another handler. i tried writing a filter that gathered the content and stuck it in $f->r->prev->notes, but it still flushes the headers of the main request. what would be the most appropriate way to go about doing this kind of thing? cheers dorian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
mod_perl, SVN::Core-related segfault condition
it's kind of a grey area as to where this problem is living - hence the double post. taking a mod_perl module that uses SVN::Core (e.g. SVN::Web), and either preloading it via PerlLoadModule/PerlModule, or the + notation in PerlResponseHandler will cause apache to segfault somewhere around modperl_perl_call_endav (the perl END block handler). SVN::Core's END block contains apr_terminate(). it seems some sort of desynch is occurring in the teardown after the initial preflight apache configuration phase. i suspect that by the time SVN::Core's END block is executed, the pool has already been freed by mod_perl. my understanding of these inner workings is fairly limited though. the platform is osx 10.3.6, apache 2.1.0-dev (worker.c), perl 5.8.5, mod_perl 1.99_18, apr and apr-util 1.0.1, and subversion 1.1.1. here's the backtrace. strangely, modperl_perl_call_endav is missing from the stack, but it shows up if you set the breakpoint to it. Breakpoint 1, 0x00610758 in modperl_perl_call_list () (gdb) bt #0 0x00610758 in modperl_perl_call_list () Reading memory from the sp at: bb00 Reading memory from the sp at: bb00 Reading memory from the sp at: bb00 #1 0x00619998 in modperl_perl_destruct () #2 0x006083f0 in modperl_interp_destroy () #3 0x006095f0 in modperl_tipool_destroy () #4 0x00608548 in modperl_interp_pool_destroy () #5 0x003a5f74 in run_cleanups (cref=0x18bc828) at memory/unix/apr_pools.c:1973 #6 0x003a5678 in apr_pool_destroy (pool=0x18bc818) at memory/unix/apr_pools.c:714 #7 0x003a55c0 in apr_pool_clear (pool=0x1806218) at memory/unix/apr_pools.c:673 #8 0x0002870c in main (argc=3, argv=0xbe88) at main.c:653 cheers .dorian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl, SVN::Core-related segfault condition
> getting things to work. I first spent hours trying to get the mandrake
> cooker binaries to work, but eventually I've built everything from source.
yeah i went that way installing it all on my mac. i typically find
i end up needing the source for reference if nothing else at one
point or another.
> >oh, and swig 1.3.22 or higher won't work, because the guy changed
> >the way it works. i used 1.3.20.
>
> really? oh my, luckily I had swig-1.3.21-5mdk
yeah, that was worth a couple hours of head-scratching.
> >i suspect though that anything trying to directly call apr_terminate()
> >from an END block would do the same. the debugger gets all fuzzy
> >when it gets into there though.
>
> Yeah, sounds like a design problem.
what exactly is required from mod_perl in the preflight config
stage? does it basically just `use' every preloaded module in the
conf to see if it can?
> Thanks I think I'm OK now and I prefer to work on my own machine :)
ok, no worries.
> Are you in rush to get this fixed? Or can I try to finish a few other
> things first (though not urgent).
a bit of one. i'm basically doing a kind of a reimplementation of
mod_negotiation, mod_dir and mod_mime (plus a couple other things)
to work on svn repositories. those modules interface directly with
the filesystem, so i need to provide a different method for emulating
various features of the filesystem. i wanted to do them up in
mod_perl with SVN::Core.
> If you have an XS module that doesn't depend on SVN that would be handy too.
yeah, that's what i'm going to be working on. just basically BEGIN
{ apr_initialize() } END { apr_terminate() }, in xs. i bet it'll
do the same thing.
.d
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl, SVN::Core-related segfault condition
oops, sorry, was in the wrong mutt window. > >what exactly is required from mod_perl in the preflight config > >stage? does it basically just `use' every preloaded module in the > >conf to see if it can? > I'm not sure what do you ask. I meant apr design problem, not modperl's > one. mod_perl does not init apr, httpd does. ah, gotcha. > BTW, I think you may have the same problem with mod_cgi. I'm not sure > whether apr_terminate is called on child process shutdown. interesting, i'll look. > OK, so post that XS module that reproduces the problem and I'll see if > something can be done. attached. you'll need to supply LIBS and INC to the Makefile.PL. > It depends on how it is implemented. The fix should be most likely in the > SVN module. It should detect that it's running under Apache or APR > environment and in which case not run the shutdown of apr environment. And > this solution will be transparent to mod_perl. i guess anything that accesses apr directly is affected. SVN::Core should probably really use APR::Pool anyway. i'll discuss it with the author. # httpd.conf PerlLoadModule APR::CrashMe -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl, SVN::Core-related segfault condition
argh, spacy today. *here* is the file. APR-CrashMe-0.01.tar.gz Description: application/tar-gz -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl, SVN::Core-related segfault condition
> But I don't see the problem that you describe. hm, i guess that makes the problem either a mac thing, an apr thing or an apache thing. > Though I've httpd-2.0 and apr-0. Does this distro crash for you? i'm rolling back now. i have httpd-2.1 for mod_dav_lock (i tried just grabbing that separately and building it against 2.0 but there have been significant enough changes in the api to thwart that), and apr-1.0 (considered 'best-available' by apache but oddly enough won't build against httpd-2.0.52). > Is it possible that your httpd and this module are compiled against > different libapr versions? yeah, they're the identical libraries, i had already made that mistake a couple weeks ago. ;). anyway, rebuilding all this is going to take a bit. will post results when i'm done. .d -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl, SVN::Core-related segfault condition
On Tue, Nov 23, 2004 at 10:08:49PM +, Dorian Taylor wrote: > > But I don't see the problem that you describe. > > hm, i guess that makes the problem either a mac thing, an apr thing > or an apache thing. apparently it's httpd-2.1. damnit. that means now i have to backport mod_dav_lock. oh well, mystery solved. .d -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ap_save_brigade
Hello, Is there a reason why ap_save_brigade hasn't been implemented? Does it have special needs? (Funnily, after googling this issue, I found I had asked the same question in 2005: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3c20050509222133.gb31...@foobarsystems.com%3E —and apparently written a patch.) Cheers, -- Dorian Taylor http://doriantaylor.com/
Re: ap_save_brigade
OK, I have a clue why ap_save_brigade wasn't implemented. I looked at
its source and it basically does this:
# XXX UNTESTED CODE
sub Apache2::Filter::save_brigade {
my ($f, $saveto, $bb, $pool) = @_;
# XXX should this be $f->r->pool?
$pool ||= $f->c->pool;
my $ret = APR::Const::SUCCESS;
for (my $b = $bb->first; !$b->is_eos; $b = $bb->next($b)) {
my $rv = $b->setaside($pool);
if ($rv == APR::Const::ENOTIMPL) {
my $len = $b->read(my $data);
# apparently this changes the bucket type?
$rv = $b->setaside($pool) if $len;
}
# check for some other kind of error
if ($rv != APR::Const::SUCCESS) {
$ret = $rv;
return $rv if $rv != APR::Const::ENOTIMPL;
}
}
# now concatenate the brigade to the target
$saveto->concat($bb);
return $ret;
}
The difference in the C version is that saveto and bb are pointers to
pointers to brigades, so if saveto is NULL, ap_save_brigade creates
one, which would be kind of icky for a Perl interface. It also means
that patch I submitted in 2005 was probably broken anyway.
There's really no reason why it couldn't be implemented in mod_perl in
a way that stipulates passing a target brigade in as input though. I'm
pretty sure it'd be a heck of a lot more efficient than that
subroutine I just wrote above.
On Mon, Jul 22, 2013 at 12:14 AM, dorian taylor
wrote:
> Hello,
>
> Is there a reason why ap_save_brigade hasn't been implemented? Does it
> have special needs?
>
> (Funnily, after googling this issue, I found I had asked the same
> question in 2005:
> http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3c20050509222133.gb31...@foobarsystems.com%3E
> —and apparently written a patch.)
>
> Cheers,
>
> --
> Dorian Taylor
> http://doriantaylor.com/
--
Dorian Taylor
http://doriantaylor.com/
Filter sequence and runtime filter manipulation for non-mod_perl filters
I'm running into the perennial problem of not being able to mix
mod_perl and Apache C filters in the necessary order. Because I also
need the C filter (mod_transform) bound only to the right
Content-Type, I figure the easiest way to make it happen would be to
write a small no-op mod_perl filter that checks $f->r->content_type
and adds mod_transform to the chain.
Of course, Apache2::Filter->add_output_filter is only capable of
adding mod_perl filters.
Grepping the mod_perl source for instances of add_output_filter, I
found this:
https://svn.apache.org/repos/asf/perl/modperl/trunk/todo/design_notes
Adding something like this to the bottom of modperl_filter_runtime_add
(in
https://svn.apache.org/repos/asf/perl/modperl/trunk/src/modules/perl/modperl_filter.c
) should make the behaviour described there partially available:
else if (SvPOK(callback)) {
char *name = SvPVX(callback);
ap_filter_t *f = addfunc(name, NULL, r, c);
if (f) return;
Perl_croak(aTHX_ "Apache filter %s could not be resolved\n", name);
}
I say "partially" because that document calls for a $ctx to be passed
into the filter, but that makes no sense for filters written in C.
The behaviour I'm looking for is something like
$f->add_output_filter('XSLT') which is the handle for mod_transform.
I'm in the process of testing this code and importing the (1.6 million
rev) SVN repository into git so I can make a proper patch.
Any insights? Am I undertaking unnecessary yak-shaving?
(Note: I was hoping to be able to cargo-cult up a re-ordered sequence
with mod_filter, but that got me nowhere. Actually, it got me a
segfault.)
Thanks,
--
Dorian Taylor
http://doriantaylor.com/
Re: Filter sequence and runtime filter manipulation for non-mod_perl filters
Correction: add_output_filter is in Apache2::Filter but is a member of $r (or $c). So I'd make a small FixupHandler, not another mod_perl filter. -- Dorian Taylor http://doriantaylor.com/
[mp2] memory access violation in $subr->run
i'm running into a problem with the execution of subrequests. the process dies in modperl_wbucket_flush. this problem occurs with the same perl code in prefork.c and worker.c on osx. note, the subrequest is run from a non-response handler (i've tried header-parser through fixup, same effect). the crash will not occur if the handler is invoked as a response handler. if subrequests aren't meant to be run from non-response handlers, i suggest trapping and throwing an error. .dorian
[mp2] fun with $r->location
i guess i had never come across it before, but i noticed today, in an attempt to use $r->location as a prefix for scrubbing path segments off the front of a request URI, that it's the innermost block that matches the URI path and that has a Perl*Handler in it that is returned, not the one in which the handler was registered. i'm curious about what would be a good way of reliably getting at the value of the proper block (let's leave LocationMatch, Files ~ etc out of this for the time being). consider this (assuming @DocumentRoot@/foo/bar/bitz exists): Options +Indexes +MultiViews PerlTypeHandler +MyApache::NopHandler SetHandler perl-script PerlHandler +MyApache::NopResponse #whatever, anything Options +FollowSymlinks suppose MyApache::NopHandler simply outputs $r->location to the error log, and MyApache::NopResponse outputs the $r->location to the UA. GET /foo/ yields the listing for /foo/, and NopHandler logs $r->location to the error log as /foo. GET /foo/bar yields the results of NopResponse (which just coughs up its $r->location, /foo/bar), and NopHandler logs $r->location as /foo/bar, even though it is registered in . GET /foo/bar/bitz yields the same results as GET /foo/bar. how would i reliably get MyApache::NopHandler to only ever emit "/foo"? cheers .dorian
[mp2] reliable methods to prevent handlers from repeating
suppose i wanted the same logic as:
return Apache::DECLINED unless $r->is_initial_req;
except that sometimes it may be necessary to serve for a subrequest,
just not more than once. the construct i tried is:
for (my $pr = $r; $pr; $pr = $pr->prev) {
if ($pr->notes->get(__PACKAGE__ . '::SEEN')) {
$r->log->debug("We've been seen already.");
return Apache::DECLINED;
}
}
$r->notes->set(__PACKAGE__ . '::SEEN', 1);
but i get no love. what's the preferred way of dealing with this?
cheers
.dorian
Re: [mp2] reliable methods to prevent handlers from repeating
> instead of looping around try $r->main->notes or $r->prev->notes hm, that loop should eventually hit all requests in the chain though, no? also, the first hit to that handler could in fact be a subrequest, so $r->main->notes may never be set. i do admit i'm cargo culting a little bit by looping over the request chain. my understanding is the aforementioned statement equates to "return declined if you find a true value in a specific note in this request or any one that has occurred since the main request.". if that's not the case, what am i missing? what technique would you use if you had to have a handler work exactly once, even though it may never be invoked as an initial request?
Re: [mp2] reliable methods to prevent handlers from repeating
On Thu, Jan 20, 2005 at 05:00:32PM -0500, Geoffrey Young wrote:
>
> > what technique would you use if you had to have a handler work
> > exactly once, even though it may never be invoked as an initial
> > request?
>
> if you're in prefork, off the top of my head I might set a perl global and
> then reset it using a cleanup handler. something like
>
> $My::Foo::seen++;
> $r->register_cleanup(sub { undef $My::Foo::seen });
hm, the reason why i did the thing with the notes is because i've
seen similar constructs in C apache modules to avoid handler looping
(i'm pretty sure mod_rewrite does it).
what about unregistering the handler from the stack? is that possible?
> so, again in prefork only, at the start of any request $My::Foo::seen should
> be false. all bets are off if you're using threads.
yeah, i'm staging in prefork (doing my best to write code that
*looks* thread-safe) currently but i'm going to be wanting to move
to worker as soon as possible.
just to clarify: what *are* $r->next/prev if not a way to access
the requests that have happened since the main, or is it only those
which have happened via internal_redirect? are the subrequests
generated by lookup_uri exempt from the list?
.d
Re: [mp2] reliable methods to prevent handlers from repeating
On Thu, Jan 20, 2005 at 02:32:59PM -0800, Philippe M. Chiasson wrote:
> Dorian Taylor wrote:
> >suppose i wanted the same logic as:
> >
> >return Apache::DECLINED unless $r->is_initial_req;
> >
> >except that sometimes it may be necessary to serve for a subrequest,
> >just not more than once. the construct i tried is:
> >
> >for (my $pr = $r; $pr; $pr = $pr->prev) {
> >if ($pr->notes->get(__PACKAGE__ . '::SEEN')) {
> >$r->log->debug("We've been seen already.");
> >return Apache::DECLINED;
> >}
> >}
> >$r->notes->set(__PACKAGE__ . '::SEEN', 1);
>
> That's because you are setting that SEEN flag in the subrequest itself,
> and that subrequest will most likely be short lived. Nobody will see that
> flag, unless that subrequest fires off another subrequest of it's own.
that's exactly it. the subrequest does in fact launch subrequests
of its own. it's possible that hits to the uri handled by this
handler may come by way of a lookup_uri from another handler, so a
test to is_initial_req or is_main won't suffice. the desired effect
is this:
GET /foo [handled by mod_foo]
`-> lookup_uri /somewhere/else [handled by this module]
`-> lookup_uri /somewhere/else/again [same, but return declined]
exactly as if the first request to /somewhere/else was the main
request and there was a test against $r->is_main, but there's no
guarantee of that.
> What you are trying to do is probably :
>
> $r->main->notes->set(__PACKAGE__ . '::SEEN', 1);
>
> And then your check becomes
>
> $r->main->notes->get(__PACKAGE__ . '::SEEN');
>
> Without a need to cycle over the requests list either.
if that was the case, couldn't i just test against $r->is_main?
if you had to deal with this scenario, what would you do?
cheers
.d
Re: [mp2] reliable methods to prevent handlers from repeating
aha. $r->lookup_uri doesn't set the calling request object into $subr->prev, according to the apache source. i can't see any way to refer to the calling request from a subrequest, unless the calling request is the main request. how frustrating. .d
Re: [mp2] reliable methods to prevent handlers from repeating
here's my solution to handler loop prevention when the initial
request to a handler isn't necessarily the main request:
sub handler {
my $r = shift;
my $mr = $r->main || $r;
if ($mr->notes->get(__PACKAGE__ . '::SEEN')) {
$r->log->debug("We are looping.");
return Apache::DECLINED;
}
$mr->notes->set(__PACKAGE__ . '::SEEN', 1);
# ... do stuff, including other lookup_uri/lookup_file requests.
$mr->notes->unset(__PACKAGE__ . '::SEEN');
return Apache::OK; # or whatever other status
}
comments?
.dorian
[mp2] retrieving the calling handler
how would i go about retrieving (mod_perl or otherwise) the name of the immediate calling handler of the current handler being executed? i'm trying to do loop checking in which a given handler may need to be executed as a result of multiple subrequests, but never back to back. e.g.: # httpd.conf ... # mod_transform uses an output filter to trap the content of a response # it lives at http://www.outoforder.cc/projects/apache/mod_transform/docs/ LoadModule transform_module modules/mod_transform.so # Apache::MyStuff cleans up uri->filename stuff PerlTypeHandler Apache::MyStuff AddOutputFilter XSLT .xml so, the scenario here is that mod_transform needs to subrequest its external entities. these external entities need to be able to run once through the type handler, but only once, as the type handler will loop indefinitely. the timeline goes as such: * request comes in from a browser, or possibly a subrequest. * Apache::MyStuff examines uri. * Apache::MyStuff may run a lookup_uri here or there (these do not trigger Apache::MyStuff's handler because some sort of state is set). * http_core (or whatever) serves up a resource, probably xml. * if it's xml, mod_transform picks up and starts trying to dereference the external entities using its filter to trap the output. * as entities are being dereferenced, Apache::MyStuff is called once again as if the subrequest lookup generated by the entity dereference was an external request. so anyway, what i'm trying to figure out is how to set a state in a handler temporarily, so that subrequests spawned from it and it only do not cause it to recurse, but if it's invoked as a subrequest or internal redirect from another handler, it does its job. if anyone can suggest anything, i'd be greatly appreciative. thanks .d
[mp2] apache 2.0.53 and ap_bucket_save
i've been reading apache list archives and source changelogs regarding a bug recently fixed in ap_bucket_save. i noticed that it was marked with a ! in xs/maps/apache_functions.map. was it unimplemented due to this bug or are there other implications to enabling this functionality? cheers .dorian
[mp2] erratum: ap_bucket_save should be ap_save_brigade
same issue, now with a function that exists. ;)
source scanning process seems to miss APR::Const::SUCCESS (and others)
Using Debian testing with the packaged versions of Apache 2.0.54-prefork
and APR 0.9.6, I ran make source_scan on the -current (rc6) tarball.
It seems that only the constant groups fopen, fprot and filetype
were found. I can only presume after looking at Apache2::ParseSource,
that the required apr headers are never seen.
I added the following which seemed to clear it up:
--- ../mod_perl-2.0.0-RC5/lib/Apache2/ParseSource.pm2005-04-14
05:19:34.0 -0700
+++ lib/Apache2/ParseSource.pm 2005-05-09 10:00:08.0 -0700
@@ -115,6 +115,8 @@
sub include_dirs {
my $self = shift;
($self->config->apxs('-q' => 'INCLUDEDIR'),
+$self->config->apxs('-q' => 'APR_INCLUDEDIR'),
+$self->config->apxs('-q' => 'APU_INCLUDEDIR'),
$self->config->mp_include_dir);
}
i'm currently running a make test (which seems to pass minus
content_length_header.t, but that's another issue).
.dorian
[mp2] [PATCH] implement ap_save_brigade
no tests currently, but there's a module on cpan that uses it.
http://search.cpan.org/~DORIAN/Apache-TrapSubRequest-0.01/
diff -ur mod_perl-2.0.0-RC4/lib/Apache/ParseSource.pm
mod_perl-2.0.0-RC4-djt/lib/Apache/ParseSource.pm
--- mod_perl-2.0.0-RC4/lib/Apache/ParseSource.pmFri Jan 7 01:17:50 2005
+++ mod_perl-2.0.0-RC4-djt/lib/Apache/ParseSource.pmFri Feb 11 08:22:37 2005
@@ -138,7 +138,7 @@
apr_optional mod_include mod_cgi
mod_proxy mod_ssl ssl_ apr_anylock
apr_rmm ap_config mod_log_config
-mod_perl modperl_ apreq);
+mod_perl modperl_ apreq mod_transform
mod_.*svn);
$unwanted = qr|^$unwanted|;
my $wanted = '';
diff -ur mod_perl-2.0.0-RC4/xs/Apache/Filter/Apache__Filter.h
mod_perl-2.0.0-RC4-djt/xs/Apache/Filter/Apache__Filter.h
--- mod_perl-2.0.0-RC4/xs/Apache/Filter/Apache__Filter.hFri Jan 7
01:17:40 2005
+++ mod_perl-2.0.0-RC4-djt/xs/Apache/Filter/Apache__Filter.hThu Feb 10
20:33:58 2005
@@ -365,3 +365,20 @@
return rc;
}
+
+static MP_INLINE
+apr_status_t mpxs_Apache__Filter_save_brigade(pTHX_ ap_filter_t *f,
+ apr_bucket_brigade *saveto,
+ apr_bucket_brigade *bb,
+ apr_pool_t *p)
+{
+apr_status_t rc = ap_save_brigade(f, &saveto, &bb, p);
+/* if users don't bother to check the success, do it on their
+ * behalf */
+if (GIMME_V == G_VOID && rc != APR_SUCCESS) {
+modperl_croak(aTHX_ rc, "Apache::Filter::save_brigade");
+}
+
+return rc;
+}
+
diff -ur mod_perl-2.0.0-RC4/xs/maps/apache_functions.map
mod_perl-2.0.0-RC4-djt/xs/maps/apache_functions.map
--- mod_perl-2.0.0-RC4/xs/maps/apache_functions.map Fri Jan 7 01:17:39 2005
+++ mod_perl-2.0.0-RC4-djt/xs/maps/apache_functions.map Thu Feb 10 22:59:18 2005
@@ -245,7 +245,9 @@
!ap_register_output_filter
-ap_remove_output_filter
-ap_remove_input_filter
-!ap_save_brigade
+~ap_save_brigade
+ mpxs_Apache__Filter_save_brigade | | \
+f, saveto, bb, p=(f->r ? f->r->pool : NULL) | save_brigade
ap_filter_flush
~ap_fflush
mpxs_Apache__Filter_fflush
source scanning process seems to miss APR::Const::SUCCESS (and others)
Using Debian testing with the packaged versions of Apache 2.0.54-prefork
and APR 0.9.6, I ran make source_scan on the -current (rc6) tarball.
It seems that only the constant groups fopen, fprot and filetype
were found. I can only presume after looking at Apache2::ParseSource,
that the required apr headers are never seen.
I added the following which seemed to clear it up:
--- ../mod_perl-2.0.0-RC5/lib/Apache2/ParseSource.pm2005-04-14
05:19:34.0 -0700
+++ lib/Apache2/ParseSource.pm 2005-05-09 10:00:08.0 -0700
@@ -115,6 +115,8 @@
sub include_dirs {
my $self = shift;
($self->config->apxs('-q' => 'INCLUDEDIR'),
+$self->config->apxs('-q' => 'APR_INCLUDEDIR'),
+$self->config->apxs('-q' => 'APU_INCLUDEDIR'),
$self->config->mp_include_dir);
}
i'm currently running a make test (which seems to pass minus
content_length_header.t, but that's another issue).
.dorian
Re: [mp2] [PATCH] implement ap_save_brigade
> How is that related?
i think that's some cargo culting that i didn't clean up. that can
be disregarded.
> So you think this approach will be faster than flattening bb on each
> filter invocation and concatenating the scalar?
honestly i didn't give it any thought. when i wrote this i just
wanted to make it go.
> sub Apache::SubRequest::run_trapped {
> my ($r, $sref) = @_;
> [...]
> $bb->flatten(my $data);
> $$sref = $data;
> $rv;
>
> why not make the API that does run_trapped($data) and save the copying of
> what could be a huge data with:
>
> sub Apache::SubRequest::run_trapped {
> my $r = shift;
> [...]
> $bb->flatten($_[1]);
yeah that makes significantly more sense. i'll update that soon.
.d
Re: [mp2] [PATCH] implement ap_save_brigade
> it'd be nice to run a benchmark. I wonder why ap_save_brigade was marked > as ! in the map file. Which normally means it's not going to be exposed. > Did you by chance look at the archives for possible references to it? there's a mention of it in the APR::Bucket manpage. i couldn't find anything else aside from a thread on dev@httpd.apache.org: http://www.mail-archive.com/dev@httpd.apache.org/msg22884.html and something else i wrote to this list asking about it. it's been labeled ! since its initial revision in svn though, apparently. perhaps dougm could shed some light? i came across the function via http://www.outoforder.cc/projects/apache/mod_transform/ , where the author uses it to retrieve arbitrary output from what may or may not actually be a file on the filesystem. i've been using it to do things like feeding subversion PROPFIND responses into xslt processors. .dorian
Re: [mp2] [PATCH] implement ap_save_brigade
> I'm not getting very far with this, Dorian. Neither httpd-dev nor apr-dev > are taking it anywhere. So at the moment ap_save_brigade is sort of an > unstable API, so other developers think we shouldn't expose it in the core > API. So at the moment you have two options: hm, this is unfortunate. > 1) write an XS code in your module which will add this code. as long as it's relatively straight-forward, i think i'd opt to do this. > 2) rewrite the code not to use this API, instead use a scalar buffer or an > array and append the data their flattening the brigades on each invocation. ap_save_brigade was unfortunately the only way i could come up with for intercepting the body of a response so that it doesn't get sent to the client, and that its contents may be used for other things. > Please let us know whether this works for you. Thanks. i can get on this in a few days. cheers .d
[mp2] enforcing the order of mod_perl with other modules
i was under the impression that for each phase in the request, modules were hooked in the order they were loaded. has this behavior changed? is there any way to force mod_rewrite, for example, to operate before mod_perl in the transhandler phase? cheers .dorian
[mp2] enforcing the order of mod_perl with other modules
i was under the impression that for each phase in the request, modules were hooked in the order they were loaded. has this behavior changed? is there any way to force mod_rewrite, for example, to operate before mod_perl in the transhandler phase? cheers .dorian
Re: [mp2] enforcing the order of mod_perl with other modules
> in apache 1.3 yes, just change the order of the modules with LoadModule > or ClearModuleList+AddModule. in 2.0 you need to alter the mod_rewrite > or mod_perl sources, unfortunately. yeah i just looked at that. what happend to Apache2::Hook? .dorian
[mp2] OR_EXEC_ON_READ
did this go away? i can't find any mention of it in the source other than the documentation and core module logic. i'm currently playing with making a container configuration, and the documentation says to set OR_EXEC_ON_READ on the req_override, but it doesn't appear to be present in Apache2::Const. bizarre. .dorian
Re: [MP2]how to catch the response body of a subrequest?
> http://search.cpan.org/dist/Apache-TrapSubRequest/lib/Apache/TrapSubRequest.pm this is actually broken. it needs the ap_save_brigade patch. i'm in a c mood so i think i'll hook up an xs version tonight. thanks for reminding me. .dorian
Re: [MP2]how to catch the response body of a subrequest?
> Or rewrite it to stash data from $bb->flatten, instead of stashing > brigades. In which case, no extra API is needed. this is true. i'll put something up on cpan tonight. .dorian
Re: Any way for a PerlHandler to know what Location block it's in?
On Wed, Jun 08, 2005 at 12:00:23PM -0400, John Siracusa wrote: > On 6/8/05, Geoffrey Young <[EMAIL PROTECTED]> wrote: > > $r->location() ? > > Duh, I'm an idiot. Thanks :) > > -John $r->location will also return whatever's in a LocationMatch, Directory and DirectoryMatch directive, should the scope of the request lay in one of those. if you're simply clipping the location off the front of the request uri you could potentially run into trouble. you can always piggyback the Location directive specifically, using the configuration api and use what you get back from that. .d
[ANNOUNCE] Apache2::TrapSubRequest 0.03
http://search.cpan.org/~dorian/ - now with working tests. 0.03 should show up soon (forgot to remove the bit about ap_save_brigade in 0.02)
Re: [ANNOUNCE] Apache2::TrapSubRequest 0.03
> Hmm, have you considered removing the _filter sub and writing > it as a closure instead? Here's some code that I've been using > for that: i suppose i could do that. today is clean-my-modules-and-get-them-on-cpan day so perhaps later. ;) .d
testing against both apache 1.x and 2.x
so i'm working on one of my modules that works in both mod_perl 1 and 2, (custom config directives, conditional makefile processing, the whole nine) and i realized i have to test against both apache 1 and 2, preferably in one sequence. now, there's APACHE_TEST_APXS, APACHE_TEST_HTTPD and whatnot, but what would be a sane way to go about retrieving both to do a single test run? .d
[ANNOUNCE] Apache(2)::DebugLog, Apache(2)::LogF
i've just completed a couple logging convenience modules. the first: http://search.cpan.org/~dorian/Apache-DebugLog-0.01/ allows for two dimensional (i.e. category, verbosity) debug logging on top of the normal debug log. the second: http://search.cpan.org/~dorian/Apache-LogF-0.01/ simply adds printf-like convenience methods to Apache::Log. Apache::DebugLog uses two custom configuration directives, PerlDebugLogLevel and PerlDebugLogDomain. mod_perl 1.x is automatically detected and the xs required to enable these directives is generated. i have not tested this yet. apache 1.x folk are welcome to try to break this for me. cheers. .dorian
Re: [ANNOUNCE] Apache(2)::DebugLog, Apache(2)::LogF
> sounds nice :) thanks ;) > if you succeed, is there any chance you could make the logic you came up > with generic enough to release it as a separate package? it would be really > nice to be able to use something like this from Makefile.PL see below... > > use Apache::ExtUtils::SomeName; > > [ whatever your API is ] > > basically, anything generic that would make it > > o easy to ship mp1 and mp2 modules together > o easy to manage mp1 and mp2 modules together where directive handlers are > involved > > would be a _huge_ benefit to the community. I know I'd jump right on board > and try to get Apache::Template working with it if the API were slick and > easy enough :) heh, actually, that's what my talk at yapc is about. "abstracting the apache configuration api". for it, i'm writing Apache(2)::AbstractConfig which i intend to provide an extensible configuration framework, making it easier to work with configuration directives. ideally, i'll be including canned data structures and merging methods, amongst other things. i was originally just going to ship this for apache 2, but then i realized the 1.x xs command table api was easy enough to access. the only tricky thing is juggling loading of mod_perl 2's symbols over mod_perl 1 in the Makefile.PL/Build.PL to get the directive stack out of the common config module. i'm sure it could be wrapped though, or possibly even some stash-fu could occur. anyway, i'm going to be sharing my results with the list before yapc, in case anyone has input on any glaring design mistakes i might make. ;) .d
EXEC_ON_READ configuration block directives
is there a working example of a block directive implementation
available? i just tried setting one up the way
http://perl.apache.org/docs/2.0/user/config/custom.html#C_Apache2__Const__RAW_ARGS_
says, and i'm not appearing to get my config subroutine run.
the config parser doesn't complain about the directive, but the
hook doesn't seem to get run.
i did the following:
package Apache2::TestBlock;
use strict;
use warnings FATAL => 'all';
use Apache2::Module ();
use Apache2::Directive ();
use Apache2::Const -compile => qw(TAKE1 RAW_ARGS OR_ALL EXEC_ON_READ);
my @directives = (
{
name=> ' __PACKAGE__ . '::TestBlock',
args_how=> Apache2::Const::RAW_ARGS,
req_override=> Apache2::Const::OR_ALL | Apache2::Const::EXEC_ON_READ
},
{
name=> 'TestScalar',
func=> __PACKAGE__ . '::TestScalar',
args_how=> Apache2::Const::TAKE1,
req_override=> Apache2::Const::OR_ALL,
},
);
Apache2::Module::add(__PACKAGE__, [EMAIL PROTECTED]);
sub TestBlock {
my ($self, $parms, $args) = @_;
warn "wtf TestBlock dude";
require Data::Dumper;
warn Data::Dumper->Dump($parms->directive->as_hash);
}
sub TestScalar {
my ($self, $parms, $arg) = @_;
warn "TestScalar: $arg";
}
1;
the config is this:
PerlLoadModule Apache2::TestBlock
TestScalar bar
am i missing anything?
.d
Re: Apache2::Upload Issue
uh, hate to bring up a no-brainer, but just out of curiosity, is the Content-length request header accurate for the encoded payload *after* it's encoded? just on the off chance that libapreq2 is stricter than libapreq1, an error like "end of file reached" would occur if there was extraneous data after the buffer of Content-Length size was filled. i'd make sure to double, nay, triple-check that value in the vb. On Mon, Jun 20, 2005 at 09:07:57PM -0400, Joe Schaefer wrote: > "D. Hageman" writes: > > > ggRIASUVORK5CYII=\r\n--AaB03x-- > ^^ > Missing an \r\n there I think. > > > -- > Joe Schaefer >
Re: Switch and mod_perl
On Thu, Jun 23, 2005 at 03:19:22PM -0400, Perrin Harkins wrote:
> On Thu, 2005-06-23 at 10:46 +0200, Jan Eden wrote:
> > could it be that mod_perl doesn't play nice with the Switch module?
>
> Isn't it a source filter? Those don't work with mod_perl.
>
> You probably shouldn't use Switch for anything serious. Even Damian
> says so.
no doubt. i consider dispatch tables much more elegant anyway.
sub stuff {
# ...
}
my %DISPATCH = (
Foo => \&stuff,
Bar => \&whatever,
);
# then ...
my $result = $DISPATCH{$param} ? $DISPATCH{$param}->(@args) : undef;
# or whatever.
.d
Apache::Test assumes Test::Builder < 0.29
apparently the reset() method of Test::Builder >= 0.29_01 has been turned into an instance-only method, thus any call to Apache::Test::test_pm_refresh() when using Apache::Test qw(-withtestmore) will cause test code to die. perhaps schwern should be notified as well? .d
Re: Apache::Test assumes Test::Builder < 0.29
> this is fixed in svn
hm weird i thought i updated before i checked again.
> why? I think that at best I was mis-using the call to reset() - it always
> accepted $self as an argument, but since it wasn't actually being used I
> ignored it, mostly because I didn't want to mess around with getting the
> $Test object. then I saw that new() was actually a singleton and smacked
> myself on the head :)
i just figured if you did, other people must have as well, and
throwing in a Carp::croak('...') unless ref $self into Test::Builder::reset
might save some head-scratching all around, but, meh. ;)
.d
debian testing vs mod_perl trunk: Makefile.PL, IO and XSLoader
the most bizarre thing popped up when i was trying to build a mod_perl deb (and from regular source) on debian testing/i386: String found where operator expected at /usr/lib/perl/5.8/IO.pm line 11, near "XSLoader::load 'IO'" (Do you need to predeclare XSLoader::load?) syntax error at /usr/lib/perl/5.8/IO.pm line 11, near "XSLoader::load 'IO'" Compilation failed in require at /usr/lib/perl/5.8/IO/Handle.pm line 9. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/IO/Handle.pm line 9. Compilation failed in require at /usr/lib/perl/5.8/IO/Seekable.pm line 9. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/IO/Seekable.pm line 9. Compilation failed in require at /usr/lib/perl/5.8/IO/File.pm line 11. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/IO/File.pm line 11. Compilation failed in require at /usr/share/perl/5.8/FileHandle.pm line 9. Compilation failed in require at /usr/share/perl/5.8/ExtUtils/Embed.pm line 6. Compilation failed in require at lib/Apache2/Build.pm line 26. BEGIN failed--compilation aborted at lib/Apache2/Build.pm line 26. Compilation failed in require at Makefile.PL line 36. BEGIN failed--compilation aborted at Makefile.PL line 36. now, if i go disambiguate XSLoader::load with parentheses, it complains of an undefined subroutine. i'm not sure what's eating XSLoader's symbols, but it's sure messing me up. has anything around this sphere been changed recently, say, in the last couple weeks? .dorian
Re: debian testing vs mod_perl trunk: Makefile.PL, IO and XSLoader
> Assuming you're aware of the renaming issue: >http://perl.apache.org/docs/2.0/rename.html > I've seen a similar error when installing a current > CPAN/svn mod_perl-2 over top of an existing mod_perl-2 > that followed the old API. Did you remove any old > mod_perl-2 installation before installing the new one? > In particular, is there an old Apache2.pm around that > may be getting picked up? weird, there was an Apache2.pm, but the mtime was dated july 14, which is strange cause i thought i'd cleaned it out far before then. anyway thanks for pointer. .d
Transfer-Encoding: chunked in requests
Hi all,
Is there a best-practice solution for dealing with requests with
chunked transfer encoding? About the only thing I could do to get it
to cooperate was this:
# pull headers
my $hdr = HTTP::Headers->new;
map { $hdr->header($_, $r->headers_in->get($_)) } keys %{$r-
>headers_in};
my ($buf, $cl) = ('', $hdr->header('Content-Length'));
if (defined $cl and $cl =~ /^\d+$/ and $cl > 0) {
$r->read($buf, $cl);
}
elsif (($hdr->header('Transfer-Encoding') || '') =~ /chunked/i) {
# AHA. chunked.
$r->setup_client_block(2); # REQUEST_CHUNKED_DECHUNK
my $chunk = '';
while (my $n = $r->get_client_block($chunk, 2048)) {
# warn $n;
$buf .= $chunk;
}
$hdr->header('Content-Length', length $buf);
$hdr->remove_header('Transfer-Encoding');
}
else {
$r->discard_request_body;
}
$r->read() seems to have no effect when the input is chunked but the
docs warn against using $r->get_client_block. I did notice that
get_client_block clobbers $chunk instead of appending to it
(originally I had it as $buf). So I'm interested if there is a more
appropriate way to do this.
For reference, I am using: Apache/2.2.11 (Ubuntu) DAV/2 SVN/1.5.4
mod_perl/2.0.4 Perl/v5.10.0
Thanks,
--
Dorian Taylor
Make things. Make sense.
http://doriantaylor.com
