Thanks for the responses.
I have been coding, these are theresults:
--------------------------
sub handler : FilterRequestHandler {
my($f, $bb) = @_;
A)
$bb->flatten(my $data);
$bb->destroy();
$this->blogum_filter(\$data,$f->r,$f->c);
my $bb_ctx = APR::Brigade->new($f->c->pool, $f->c->bucket_alloc);
my $b = APR::Bucket->new($bb_ctx->bucket_alloc,$data);
$bb_ctx -> insert_tail($b);
$f->pass_brigade($bb_ctx);
return Apache::OK;
Each brigade is flatten to $data and destroyed.
$data is rightly changed.
A new brigade is created.
A new $data-bucket is created and inserted in the new brigade.
The new brigade is passed to the SAME filter.
This option hangs both firefox 0.92 and explorer 6.0, that does not download
anything.
B)
--- $f->pass_brigade($bb_ctx);
+++ $f->next->pass_brigade($bb_ctx);
This change makes a difference.
Firefox download the page but waits 8-10 seconds to finish the download (i see
it because
when it
finishes the javascript code engage, not before.
But surprisingly Explorer goes rightly, without expecting nothing more.
Returning OK or DECLINED makes no difference.
C)
my $b = $bb->first;
warn 'START BRIGADE ---------------------'.$bb;
while ($b) {
last if $b->is_eos;
$b->read(my $data);
warn 'BUCKET DATA '.$b."\n".$data;
$b = $bb->next($b);
}
warn 'final brigade';
return Apache::OK;
I did this to see simply if buckets were ordered.
If i have the data as A-B-C:
brigade 1) APR::Brigade=SCALAR(0xfb0a7c)
bucket 1) APR::Bucket=SCALAR(0x9c1a2c)
content: A
brigade 2) APR::Brigade=SCALAR(0xfb0a7c)
bucket 1) APR::Bucket=SCALAR(0x9c1a2c)
content: B
brigade 3) APR::Brigade=SCALAR(0xfb0a7c)
bucket 1) APR::Bucket=SCALAR(0x9c1a2c)
content: A
bucket 2) APR::Bucket=SCALAR(0x111f728)
content: C
But changing the return to DECLINED the bucket 1 of brigade 3 dissapeared and
all went
right, and
the page loaded rightly as well.
D)
my $b = $bb->first;
while ($b) {
last if $b->is_eos;
$b->read(my $data);
$this->blogum_filter(\$data,$f->r,$f->c);
my $nb = APR::Bucket->new($bb->bucket_alloc,$data);
$b->insert_before($nb);
$b->remove; # it is destroyed automatically
$b = $bb->next($b);
}
return Apache::DECLINED;
Happily this option goes smoothly with both browsers. The buckets are altered
and DECLINED is
returned. Returning OK does not work.
E)
my $bb_ctx = APR::Brigade->new($f->c->pool, $f->c->bucket_alloc);
while (!$bb->is_empty) {
my $b = $bb->first;
if ($b->is_eos) {
$bb_ctx -> insert_tail($b);
last;
}
if ($b->read(my $data)) {
$this -> blogum_filter(\$data,$f->r,$f->c);
my $b = APR::Bucket->new($bb->bucket_alloc,$data);
}
$b -> remove;
$bb_ctx -> insert_tail($b);
}
my $rv = $f->next->pass_brigade($bb_ctx);
return $rv unless $rv == APR::SUCCESS;
return Apache::OK;
This is the "official" option. Both explorer and firefox hangs up, waiting
without showing
anything. Mostt of times firefox causes apache to crash.
F)
my $tp = 'g ';
my $pb = APR::Bucket->new($bb->bucket_alloc,$tp);
while (!$bb->is_empty) {
my $b = $bb->first;
if ($b->is_eos) {
$pb->insert_after($b);
last;
}
if ($b->read(my $data)) {
$this -> blogum_filter(\$data,$f->r,$f->c);
my $nb = APR::Bucket->new($bb->bucket_alloc,$data);
$pb->insert_after($nb);
}
$b->remove;
}
$bb->insert_tail($pb);
return Apache::DECLINED;
Although docs seem to indicate that inserting a bucket after a brigade include
all atached
buckets,
the only i see is two-three times the letter g.
G)
my $buckets = [];
while (!$bb->is_empty) {
my $b = $bb->first;
if ($b->is_eos) {
push @$buckets, $b;
last;
}
if ($b->read(my $data)) {
$this -> blogum_filter(\$data,$f->r,$f->c);
my $nb = APR::Bucket->new($bb->bucket_alloc,$data);
push @$buckets, $nb;
}
$b->remove;
}
$bb->insert_tail($_) foreach (@$buckets);
return Apache::DECLINED;
This solution ws expected to work as D), but it works as B). That means that
Firefox waits
8-10
sedonds to finish the download.
All this is confusing. I am going to work with D) but i don't understand what
happens
here. The
Main conclusion is that what is said in docs doesn't work for me.
Thanks.
---------------------------------------
>"eps com estem" <a
href="javascript:sendMsg('<[EMAIL PROTECTED]>');"><[EMAIL PROTECTED]></a>
writes:
>[...]
>> 1)- First thing is that if i am creating a new bucket for a new
>> brigade, the line
>> my $b = APR::Bucket->new($bb->bucket_alloc,$data);
>> should be
>> my $b = APR::Bucket->new($bb_ctx->bucket_alloc,$data);
>> or that's what i think(?).
>Makes no difference; they all should reference the
>same internal allocator (f->c->bucket_alloc).
>> With this change in the first codes the situation however doesn't
>> change.
>>
>> 2)- Second thing is that, in a try to "finish" the transaction i
>> wanted to create an eos stream. Docs say
>> use APR::Bucket ();
>> use Apache::Connection ();
>> my $ba = $c->bucket_alloc;
>> my $eos_b = APR::Bucket::eos_create($ba);
>Syntactically correct, but normally you shouldn't create
>your own eos bucket. The upstream filter will eventually
>send one to your filter, so its better to just pass *that*
>one along when it comes.
>> so
>> my $eos_b = APR::Bucket->eos_create($f->c->bucket_alloc);
>> should work ... or not ...
>No that doesn't work. The error message is correct,
>eos_create only takes one argument: an APR::BucketAlloc
>object.
>> If i put
>> my $eos_b = APR::Bucket::eos_create($f->c->bucket_alloc);
>> there's no more Internal Error, but page appears (after 8-10 seconds)
>> truncated.
>Right. Your filter may be invoked multiple times
>for a single request. By inserting the eos
>bucket too soon, you wind up confusing both apache
>and the browser. The eos bucket tells downstream
>filters that no more content will be coming, so
>apache won't send any more data even if the browser
>is expecting it.
>> a) :: is not equal to ->? i though yes but i have not verified
>They're different. The -> is a (class) method call,
>so perl will do an OO lookup for the proper method
>and adjust @_ accordingly. In your example, these
>two (erroneous) invocations are the same
> APR::Bucket->eos_create($data)
> APR::Bucket::eos_create("APR::Bucket", $data)
>> b) an eos ends only the brigade, isn't it? or it ends the filter?
>Ends the *request*. Each brigade / filter invocation
>represents only a part of the full request.
>>
>> 3)- Third, i think $bb should be destroyed instead of cleaned up, am i
>> right?
>Both the brigade and the buckets within it will be
>cleaned up automatically when the connection dies.
>It's ok to cleanup/destroy a bucket brigade before that,
>but you don't need to worry about this unless you
>really want to.
>I suggest you try working through the example at
> <URL:
> <a
href="/app/message?l=es&o=8&url=http%3A%2F%2Fperl%2Eapache%2Eorg%2Fdocs%2F2%2E0%2Fuser%2Fhandlers%2Ffilters%2Ehtml"
target="_blank">http://perl.apache.org/docs/2.0/user/handlers/filters.html</a>
> #Bucket_Brigade_based_Output_Filters
> >
>If you have problems/questions with the documented
>examples, report them and the docs will likely improve.
>Best wishes.
>--
>Joe Schaefer
>--
>Report problems: <a
href="/app/message?l=es&o=8&url=http%3A%2F%2Fperl%2Eapache%2Eorg%2Fbugs%2F"
target="_blank">http://perl.apache.org/bugs/</a>
>Mail list info: <a
href="/app/message?l=es&o=8&url=http%3A%2F%2Fperl%2Eapache%2Eorg%2Fmaillist%2Fmodperl%2Ehtml"
target="_blank">http://perl.apache.org/maillist/modperl.html</a>
>List etiquette: <a
href="/app/message?l=es&o=8&url=http%3A%2F%2Fperl%2Eapache%2Eorg%2Fmaillist%2Femail%2Detiquette%2Ehtml"
target="_blank">http://perl.apache.org/maillist/email-etiquette.html</a>
---------------------------------------------------------
Esta Navidad, sé más original ¿Te atreves a enviar una postal con tu voz?
http://greetingmania.ya.com
Ya.com ADSL Router Wi-Fi: Sólo 29,90 €/mes + IVA*. Router + Antivirus y
firewall ¡Gratis! http://acceso.ya.com/adsl/256router
--
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
