AW: Reading post-data
> > Yes, this code works and I am using it, too. But the
> documentation says,
> > you can use
> >$r->read($buf, $r->headers_in->{'content-length'}
>
> this statement reads the entire request content in one iteration by
> using a read buffer size equal to the content-length of the request.
>
> > http://perl.apache.org/docs/2.0/user/porting/compat.html
> > I want to know if the documentation is wrong, and if it is wrong, it
> > should be corrected!
>
> I'm not sure if there is anything wrong with it, seems like a
> good way
> to slurp the request content.
>
> If the request content is large and you are performing a memory
> intensive operation on each chunk then you might want to read
> in a while
> loop as in your first example and perform some work on each chunk, so
> that the overall memory usage is low.
>
Please read my initial posting:
...
But there are two problems with
$r->read($buf, $r->headers_in->{'content-length'}
1. An input filter can change the length of the incoming content. It can
be longer than before, but the content-length header will not be
changed, so some data will be missing.
2. If the POST data are sent per chunked encoding, there is no
content-length header at all.
Peter
Re: Reading post-data
Reif Peter wrote:
Reif Peter wrote:
my $postdata = "";
while ($r->read(my $buf, 8192)) { $postdata .= $buf; }
You should ofcourse select a read-buffer size that will best
suite your
setup. I do not know what would be the most optimal setting here.
Yes, this code works and I am using it, too. But the documentation says,
you can use
$r->read($buf, $r->headers_in->{'content-length'}
this statement reads the entire request content in one iteration by
using a read buffer size equal to the content-length of the request.
http://perl.apache.org/docs/2.0/user/porting/compat.html
I want to know if the documentation is wrong, and if it is wrong, it
should be corrected!
I'm not sure if there is anything wrong with it, seems like a good way
to slurp the request content.
If the request content is large and you are performing a memory
intensive operation on each chunk then you might want to read in a while
loop as in your first example and perform some work on each chunk, so
that the overall memory usage is low.
Re: Reading post-data
> Reif Peter wrote:
> > Unfortunately you cannot tell $r->read to read just all of
> the data, you
> > must provide a length.
> >
> > How do I solve this problems.
>
> $r->read will return 0 when no more data is available. I have
> been using
> the following simple code with success:
>
> my $postdata = "";
> while ($r->read(my $buf, 8192)) { $postdata .= $buf; }
>
> You should ofcourse select a read-buffer size that will best
> suite your
> setup. I do not know what would be the most optimal setting here.
>
Yes, this code works and I am using it, too. But the documentation says,
you can use
$r->read($buf, $r->headers_in->{'content-length'}
http://perl.apache.org/docs/2.0/user/porting/compat.html
I want to know if the documentation is wrong, and if it is wrong, it
should be corrected!
Peter
AW: Reading post-data
> Reif Peter wrote:
> > Unfortunately you cannot tell $r->read to read just all of
> the data, you
> > must provide a length.
> >
> > How do I solve this problems.
>
> $r->read will return 0 when no more data is available. I have
> been using
> the following simple code with success:
>
> my $postdata = "";
> while ($r->read(my $buf, 8192)) { $postdata .= $buf; }
>
> You should ofcourse select a read-buffer size that will best
> suite your
> setup. I do not know what would be the most optimal setting here.
>
Yes, this code works and I am using it, too. But the documentation says,
you can use
$r->read($buf, $r->headers_in->{'content-length'}
http://perl.apache.org/docs/2.0/user/porting/compat.html
I want to know if the documentation is wrong, and if it is wrong, it
should be corrected!
Peter
Re: Reading post-data
Reif Peter wrote:
Unfortunately you cannot tell $r->read to read just all of the data, you
must provide a length.
How do I solve this problems.
$r->read will return 0 when no more data is available. I have been using
the following simple code with success:
my $postdata = "";
while ($r->read(my $buf, 8192)) { $postdata .= $buf; }
You should ofcourse select a read-buffer size that will best suite your
setup. I do not know what would be the most optimal setting here.
Cheers,
-- Jani
Reading post-data
In
http://perl.apache.org/docs/2.0/user/porting/compat.html
I read:
if one wishes to simply read POST data, there is the more modern filter
API, along with continued support for read(STDIN, ...) and
$r->read($buf, $r->headers_in->{'content-length'})
But there are two problems with
$r->read($buf, $r->headers_in->{'content-length'}
1. An input filter can change the length of the incoming content. It can
be longer than before, but the content-length header will not be
changed, so some data will be missing.
2. If the POST data are sent per chunked encoding, there is no
content-length header at all.
Unfortunately you cannot tell $r->read to read just all of the data, you
must provide a length.
How do I solve this problems.
Peter
RE: Reading post data from separate handlers
Hi, > > I have a problem that hopefully somebody has encountered or > can point me in the right direction. > > We use the latest embperl 1.xxx release on linux. I have > created a handler to do authentication before the embperl > handler is run. This new handler needs to read data from the > post each request. However once read is called on the Apache > object you cannot call it again. This in turns cripples > embperl because it no longer has the post data. Is there any > way to be able to read the post data from multiple handlers? > Since you use Embperl 1, I guess you use Apache 1.3, where no filter chain exists. In this case you cannot read the postdata twice. You need to read the data in your first handler and pass it over to Embperl. Gerald ** Virus checked by BB-5000 Mailfilter **
Re: Reading post data from separate handlers
Blayne Bayer wrote: I have a problem that hopefully somebody has encountered or can point me in the right direction. We use the latest embperl 1.xxx release on linux. I have created a handler to do authentication before the embperl handler is run. This new handler needs to read data from the post each request. However once read is called on the Apache object you cannot call it again. This in turns cripples embperl because it no longer has the post data. Is there any way to be able to read the post data from multiple handlers? If you are part of the filter stack, you can 'sniff' - read ahead and set aside - the data coming in from the client. Other filters installed after your filter will repeatedly call, and you return the set-aside data. You can look at the apreq2 library with httpd-2 to assist you with this.
Reading post data from separate handlers
I have a problem that hopefully somebody has encountered or can point me in the right direction. We use the latest embperl 1.xxx release on linux. I have created a handler to do authentication before the embperl handler is run. This new handler needs to read data from the post each request. However once read is called on the Apache object you cannot call it again. This in turns cripples embperl because it no longer has the post data. Is there any way to be able to read the post data from multiple handlers? Thanks for any help or suggestions. Blayne
Re: reading post data.
Dermot Paikkos wrote: Does that mean there is no performance penalty or other price for using CGI instead of libapreq? I've done know benchmarks, but I'd be hard pressed to find anycase where XS code is slower then PERL code. libapreq2 is a thin PERL wrapper around the C interfaces written in XS. -- END -- Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com
Re: reading post data.
On 23 Apr 2005 at 16:16, jonathan vanasco wrote: > RC5 is slightly different from the namespace stuff, and you need to > run one of the svn branches of libapreq -- either trunk or multi-env > -- its under active development right now > > personally, i think libapreq is the best way to read GET/POST data > under MP2 > > > On Apr 23, 2005, at 3:56 PM, Michael Schout wrote: Does that mean there is no performance penalty or other price for using CGI instead of libapreq?
Re: reading post data.
Michael Schout wrote: I am wondering what the best way is to read POST data under MP2. In MP1, I was using $r->content for this. In MP2, $r->content does not exist, so I used the version from an earlier copy of Apache::compat, which was using $r->get_client_block() instead. Now, get_client_block() is apparently deprecated, and I am left with the choice of: 1) using $r->read(). CGI.pm apparently does it this way. 2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides content() this way. 3) some other way that I do not know about :). I am unclear what the advantages are for either approach. The APR::Brigade docs do not really clarify this for me. Does anyone know which of these methods is better and why? Michael, as Jonathan has replied it's now the job of CGI.pm, APR::Request and other modules to provide this service. In the lack of it, you can use the following code: http://svn.apache.org/viewcvs.cgi/perl/modperl/trunk/t/lib/TestCommon/Utils.pm?rev=160947&view=markup (see the read_post sub in it, drop the debug code to not add the overhead) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: reading post data.
works in RC4 + libapreq 2.04
use Apache::Request()
sub handler
{
my $r = shift;
my $apr = Apache::Request->new( $r , DISABLE_UPLOADS=>0,
POST_MAX=>10 );
$stringvalue = $apr->param($stringname);
}
RC5 is slightly different from the namespace stuff, and you need to run
one of the svn branches of libapreq -- either trunk or multi-env -- its
under active development right now
personally, i think libapreq is the best way to read GET/POST data
under MP2
On Apr 23, 2005, at 3:56 PM, Michael Schout wrote:
I am wondering what the best way is to read POST data under MP2.
In MP1, I was using $r->content for this. In MP2, $r->content does not
exist, so I used the version from an earlier copy of Apache::compat,
which was using $r->get_client_block() instead.
Now, get_client_block() is apparently deprecated, and I am left with
the
choice of:
1) using $r->read(). CGI.pm apparently does it this way.
2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides
content() this way.
3) some other way that I do not know about :).
I am unclear what the advantages are for either approach. The
APR::Brigade docs do not really clarify this for me.
Does anyone know which of these methods is better and why?
Regards,
Michael Schout
reading post data.
I am wondering what the best way is to read POST data under MP2. In MP1, I was using $r->content for this. In MP2, $r->content does not exist, so I used the version from an earlier copy of Apache::compat, which was using $r->get_client_block() instead. Now, get_client_block() is apparently deprecated, and I am left with the choice of: 1) using $r->read(). CGI.pm apparently does it this way. 2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides content() this way. 3) some other way that I do not know about :). I am unclear what the advantages are for either approach. The APR::Brigade docs do not really clarify this for me. Does anyone know which of these methods is better and why? Regards, Michael Schout
Re: reading POST data problem
Stas Bekman wrote:
eps com estem wrote:
Hi, i had already tested the $r->read but it did not work, now i have
found why.
$r->read(my $buffer, $len)
only works if $buffer is a string.
$r->read($ref->{buffer}, $len)
does not work, as $ref->{buffer} is empty. And that was what i was
using, so i though a
long time ago it was some kind of windows-problem.
Using directly a string it works, thanks!
You are correct, it should work just as well. Let's fix that.
Please apply this patch. It should fix the problem. It'll go into cvs
once I complete the testing. I've also updated the rest of
($filter|$bucket|etc)->read() functions. Let us know whether it has
solved the problem for you as well.
What happens is that when you pass an autovivified hash value, it
doesn't have any entry yet, not even undef. So in order to set it one
must run the magic set, which we didn't.
Index: xs/Apache/RequestIO/Apache__RequestIO.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h,v
retrieving revision 1.52
diff -u -r1.52 Apache__RequestIO.h
--- xs/Apache/RequestIO/Apache__RequestIO.h 2 Jul 2004 23:20:47
- 1.52
+++ xs/Apache/RequestIO/Apache__RequestIO.h 12 Jul 2004 07:10:21 -
@@ -199,6 +199,9 @@
sv_setpvn(buffer, "", 0);
}
+/* must run any set magic */
+SvSETMAGIC(buffer);
+
return nrd;
}
@@ -253,6 +256,9 @@
else {
sv_setpvn(bufsv, "", 0);
}
+
+/* must run any set magic */
+SvSETMAGIC(bufsv);
return newSViv(total);
}
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
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: reading POST data problem
eps com estem wrote:
Hi, i had already tested the $r->read but it did not work, now i have found why.
$r->read(my $buffer, $len)
only works if $buffer is a string.
$r->read($ref->{buffer}, $len)
does not work, as $ref->{buffer} is empty. And that was what i was using, so i though a
long time ago it was some kind of windows-problem.
Using directly a string it works, thanks!
You are correct, it should work just as well. Let's fix that.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
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: reading POST data problem
Hi, i had already tested the $r->read but it did not work, now i have found why.
$r->read(my $buffer, $len)
only works if $buffer is a string.
$r->read($ref->{buffer}, $len)
does not work, as $ref->{buffer} is empty. And that was what i was using, so i though a
long time ago it was some kind of windows-problem.
Using directly a string it works, thanks!
>eps com estem wrote:
>> Hi.
>>
>> I used to read POST data with the sentence
>> read (STDIN,$var,$r_headers->{'Content-length'});
>> When the handler was invoked after submitting the formulary.
>>
>> But, lately i changed the handler configured in apache.conf by a parsing URI
>> module. There
>> i catch the direction of the form submit and from there i call the handler.
>> So the call is in a different phase (a previous phase), and then the same order
>> read (STDIN,$var,$r_headers->{'Content-length'});
>> hangs the server.
>> (The phase is PerlTransHandler +Blogum::BlogumURI)
>>
>> I have guessed that at that phase the STDIN is still not closed (?) and that's why
>> the
>> server waits forever.
>> ($r_headers->{'Content-length'} has already the num of content-length).
>>
>> So my question is, can i read the POST data at PerlTransHandler stage?
>> If yes, then i am doing something wrong, if not, there is some workaround or i will
>> have
>> to go back to my original handlers?
>You can, but not the way you did. When you use 'SetHandler perl-script'
>STDIN gets tied to the request data only during the response phase.
>http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
>If you want to do it earlier, use the modperl API directly.
> $r->read(my $buffer, $len)
>http://perl.apache.org/docs/2.0/api/Apache/RequestIO.html#C_read_
>> Apache/2.0.48 (Win32) mod_perl/1.99_13-dev Perl/v5.8
>--
>__
>Stas BekmanJAm_pH --> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:[EMAIL PROTECTED]');">mailto:[EMAIL
>PROTECTED] http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>--
>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
-
Descubre tu futuro para este verano: aventuras, amores, trabajo... Horóscopo en
Ya.com: http://www.astrocentro.com/ya
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
Re: reading POST data problem
eps com estem wrote:
Hi.
I used to read POST data with the sentence
read (STDIN,$var,$r_headers->{'Content-length'});
When the handler was invoked after submitting the formulary.
But, lately i changed the handler configured in apache.conf by a parsing URI module.
There
i catch the direction of the form submit and from there i call the handler.
So the call is in a different phase (a previous phase), and then the same order
read (STDIN,$var,$r_headers->{'Content-length'});
hangs the server.
(The phase is PerlTransHandler +Blogum::BlogumURI)
I have guessed that at that phase the STDIN is still not closed (?) and that's why the
server waits forever.
($r_headers->{'Content-length'} has already the num of content-length).
So my question is, can i read the POST data at PerlTransHandler stage?
If yes, then i am doing something wrong, if not, there is some workaround or i will
have
to go back to my original handlers?
You can, but not the way you did. When you use 'SetHandler perl-script'
STDIN gets tied to the request data only during the response phase.
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
If you want to do it earlier, use the modperl API directly.
$r->read(my $buffer, $len)
http://perl.apache.org/docs/2.0/api/Apache/RequestIO.html#C_read_
Apache/2.0.48 (Win32) mod_perl/1.99_13-dev Perl/v5.8
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
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
reading POST data problem
Hi.
I used to read POST data with the sentence
read (STDIN,$var,$r_headers->{'Content-length'});
When the handler was invoked after submitting the formulary.
But, lately i changed the handler configured in apache.conf by a parsing URI module.
There
i catch the direction of the form submit and from there i call the handler.
So the call is in a different phase (a previous phase), and then the same order
read (STDIN,$var,$r_headers->{'Content-length'});
hangs the server.
(The phase is PerlTransHandler +Blogum::BlogumURI)
I have guessed that at that phase the STDIN is still not closed (?) and that's why the
server waits forever.
($r_headers->{'Content-length'} has already the num of content-length).
So my question is, can i read the POST data at PerlTransHandler stage?
If yes, then i am doing something wrong, if not, there is some workaround or i will
have
to go back to my original handlers?
Thanks.
Apache/2.0.48 (Win32) mod_perl/1.99_13-dev Perl/v5.8.2
-
Descubre tu futuro para este verano: aventuras, amores, trabajo... Horóscopo en
Ya.com: http://www.astrocentro.com/ya
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
