RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote: Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? Check out the guide: http://perl.apache.org/guide/ Check out the books: http://perl.apache.org/docs/offsite/books.html Check out the success stories: http://perl.apache.org/outstanding/success_stories/index.html TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 signature.asc Description: This is a digitally signed message part
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Jesse Erlbaum wrote: Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. I like to think that Part III (Chapters 11-17) of the mod_perl Developer's Cookbook does some of that. authentication is a good example of how mod_perl enables life outside of CGI scripting. if you require authentication in your application, auth handlers allow you to entirely remove authentication from your content handlers. mod_perl allows you to let your content handlers to focus on content - all other parts of your application (authentication, session management, proxying, URL rewriting tricks, etc) can programmed at the server level via other parts of the request cycle. I'm talking about this at a very basic level at OSCon this year (as I did last year), but you might be interested in my slides from YAPC2002 to get a general feel for it (and ApacheCon if you want to see the more twisted side of what mod_perl opens up). http://www.modperlcookbook.org/~geoff/slides/ HTH --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Hello, GYmod_perl allows you to let your content handlers to focus on content - GYall other parts of your application (authentication, session management, GYproxying, URL rewriting tricks, etc) can programmed at the server level GYvia other parts of the request cycle. I think the question isn't why is Apache::Registry not sufficient to handle all functions within an HTTP request but why is it bad to use Apache::Request specifically for the content generation phase? Perrin had some good practical reasons for this--caused by the generated-namespace, sub-wrapped, eval'ed nature of Apache::Registry. I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. I think it's a fine tool for simple content generation scripts and that it doesn't limit you at all in that aspect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this http://www.perl.com/pub/a/2002/02/20/css.html while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool. other cool stuff comes at the end of this talk, http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz which touches on Apache::Registry-as-legacy-CGI-wrapper limitations see also http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz which handles the issue of merging legacy CGI Registry scripts with POST data issues and http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz which addresses the fact that Registry does not properly handle HEAD requests. given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection. --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs.mod_perlhandler philosophy)
On Wed, 2003-07-02 at 20:38, Andrew Ho wrote: I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script I would phrase it differently and say that there are nice things you can do when you embrace the fact that you're in a persistent environment. You can do a lot of things in ways that are compatible with both CGI and mod_perl, by checking the environment and acting appropriately, but it can be a pain when you want to take advantage of cleanup handlers, preloaded data, persistent connections, etc. You can do all this from A::R, but once you've decided to write something that is not going to work under CGI I can't see any reason to use A::R anymore. At that point, it's just an artificial construct that adds complexity to your system. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. People often say this. I just don't see it. Apache::Reload works just as well. My dev server restarts in about a second, so I always restart it when I make a change just to feel confident that I'm not seeing any residual effects from previous code. The whole reload thing is not perfect anyway, and people have had problems with A::R's reload when working with code that has closures in it. My opinion is that you should use A::R if you need CGI (or SpeedyCGI, etc.) compatibility, but use handlers otherwise. - Perrin
Re: apache::request parse() doesn't capture abort error
Hector Pizarro [EMAIL PROTECTED] writes:
[...]
If the user closes the popup in the middle of an upload, Apache::Request
parse() isn't throwing any error, and all the following code in my module
savesthe file incomplete in the system, which of course is garbage data.
Is this a bug, an incomplete feature, or is my configuration?
It's probably a bug in c/apache_multipart_buffer.c. We may not
do error-checking well enough on fill_buffer().
If parse is supposed to return an error code, which one is that? 206 =
HTTP_PARTIAL_CONTENT?
No, that's not an error code. Since the error here seems
to arise from ap_get_client_block, $r-status should probably
be -1.
Ok, now let's suppose that this error is fixed.
With a patch, I hope ;-).
I want to do several uploads fromthe same popup at once, so I have 5
file boxes in the form. If the user closesthe popup before the process
ends, i'd like to save only the completed files, how could I check
which files are correctly uploaded, and which ones are incomplete?
You could just ignore the final upload object, which has no - next
pointer:
for (my $u = $req-upload; $u $u-next; $u = $u-next) {
# do something with $u
}
--
Joe Schaefer
Re: Apache::Request
Ewald Geschwinde wrote:
I have read that the param Method had been deprecated
$r-param('value'):
How do I get now the variables from a submitted form ??
now? when? nothing has changed with Apache::Request. No April Fools jokes here.
__
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: Apache::Request: analyse output.
Andrew Alakozow wrote:
Hello,
I use Apache::FakeRequest to test perl handlers without firing up Apache.
Testting is supposed to be done by matching output of handlers with some
regexps. But the print method of Apache::Request prints to STDOUT, so to
get output I applied following patch to it:
10c10,17
sub print { shift; CORE::print(@_) }
---
sub print {
my $self = shift;
if (exists $$self{fr_output}) {
$$self{fr_output} .= join ('', @_);
} else { CORE::print(@_) }
}
Now, if fr_output method is defined all output comes there.
my $request = Apache::FakeRequest-new(fr_output = '', ...);
If it's right thing may be this patch should go to CPAN, and if it's not
right, I'll be glad to hear how to do it right.
You can use IO::String for this purpose:
http://perl.apache.org/docs/1.0/guide/porting.html#Redirecting_STDOUT_into_a_Scalar
__
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: Apache::Request incompatible with CGI ?
I downloaded Apache::Request from CPAN and I have version 0.31. My C compiler is gcc 2.96 aiya. libapreq 0.31 is the one that likes to append whatever it is that one just uploaded to it to its heap until it starves your machine of memory, if i recall correctly. it was fixed in 0.31_03 i believe but it looks like 1.1 was released last week. .dorian
Re: Apache::Request + Apache::Filter
Hello,
We use this patch (on Apache::Filter 1.019) and it works ok. It won't
get you up and running with Apache::Registry, but it will do if you can
initialize the filter yourself.
Add this to Filter.pm:
sub Apache::Request::filter_register {
my $r= shift;
ISA = qw(Apache::Request);
Apache::filter_register ($r);
}
Here is the usage in your own code (this is slightly subtle):
my $old_r = Apache-request();
my $filtered_r = Apache::Request-instance($old_r)-filter_register();
That should do the trick. There is probably a cleaner way to do it, but
this has worked for us.
John
On Tuesday, November 12, 2002, at 02:22 PM, Richard Clarke wrote:
List,
Can anyone tell me if a module exists that combines these two
modules so
that, for example, when using Apache::Dispatch one can create an
instance of
Apache::Request in the handler without clobbering the overridden
methods
sent as part of the Apache::Filter object. Before I try and do this I
wondered if it had already been done? Apache::RequestFilter would make
sense
to me but something like this doesn't seem to exist on CPAN.
Ric
Re: Apache::Request
On Mon, 26 Aug 2002, Ufuk Yuzereroglu wrote: I dont know if this is the right place to ask but I just cant install Apache::Request. When calling 'make', make cant find any of the header files. Can anyone tell me where I did go wrong? Did you install mod_perl and apache successfully on the same machine? -- best regards, randy kobes
Re: Apache::Request $apr-param; problems.
* Wes Cravens [EMAIL PROTECTED] [2002-07-05 10:48]: however if this routine is called more than once with the same $r object then the second time there are no params. It's as if calling $apr-param strips them off $r. That's not clever. I can't find anything in the documentation that says it would behave like that. Are you POSTing the data? You can't read that more than once. Look at (for example) http://perl.apache.org/release/docs/1.0/guide/snippets.html#Reusing_Data_from_POST_request or check out Apache::RequestNotes/ (darren) -- The language Unix is vastly more inconsistent than the language Perl. And guaranteed to remain that way, forever and ever, amen. -- Larry Wall
RE: Apache::Request $apr-param; problems.
Fantastic... top marks for concise and useful answer of the month :-) Shame that the first paragraph of that link isn't in Programming Apache Modules...or (at least afaict) the perldoc's. Cheers, Wes -Original Message- From: darren chamberlain [mailto:[EMAIL PROTECTED]] Sent: 05 July 2002 15:57 To: modperl Subject: Re: Apache::Request $apr-param; problems. * Wes Cravens [EMAIL PROTECTED] [2002-07-05 10:48]: however if this routine is called more than once with the same $r object then the second time there are no params. It's as if calling $apr-param strips them off $r. That's not clever. I can't find anything in the documentation that says it would behave like that. Are you POSTing the data? You can't read that more than once. Look at (for example) http://perl.apache.org/release/docs/1.0/guide/snippets.html#Reusin g_Data_from_POST_request or check out Apache::RequestNotes/ (darren) -- The language Unix is vastly more inconsistent than the language Perl. And guaranteed to remain that way, forever and ever, amen. -- Larry Wall
Re: Apache::Request $apr-param; problems.
or check out Apache::RequestNotes/ you'll also want to check out using Apache::Request-instance() over Apache::Request-new() HTH --Geoff
RE: Apache::Request $apr-param; problems.
or check out Apache::RequestNotes/ you'll also want to check out using Apache::Request-instance() over Apache::Request-new() That is indeed the three second code fix that I implemented.
Re: Apache::Request - Win32
That worked!! I had installed the ActiveState libapreq. Thanks for your help on this! On Sun, 23 Jun 2002, Levon Rubin Barker wrote: Hello. I'm sure this is a simple problem, but I'm a noob at mod_perl and could use some help. I am running WinXP, Apache 1.3.26, Mod_perl 1.27_01-dev with libapreq 0.31/ The problem I am having is ... I get the following in the Apache Error log. [Sun Jun 23 08:44:06 2002] [error] Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at (eval 12) line 9. Did you get libapreq from ActiveState's repository? This one just has the .pm files - none of the C stuff - which might also explain this error. Try the libapreq available from ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/libapreq.ppd best regards, randy _ Sign up for your Free RecHockey email at http://www.rechockey.net.
Re: Apache::REquest on cygwin
On Fri, 4 Jan 2002, Dan Horne wrote: I've been trting to get mod_perl working under cygwin. I've manages to install both Apache and mod_perl and have tested the earlier scripts in the O'Reilly Writing Apache Modules -e.g. The guestbook app. However, I can't get Apache::Request installed. The tail end of the make is: : lots of undefined symbols : /tmp/libapreq-0.33/Request/../blib/arch/auto/libapreq/libapreq.a(apache_mult ipart_buffer.o)(.text+0x377):apache_multipart_buffer.c: undefined reference to `ap_make_table' [ ... ] I'm not very familiar with building things on cygwin, but you may have to specify the location and name of the apache lib to link against. best regards, randy kobes
Re: apache::request and other newbie questions
John Michael wrote: I have a modperl script that uses. cgi.pm and actually I have been importing my on cgi params from get and post but do use cgi.pm for cookies. I have read in some other emails and now in the guide that it is faster to use Apache::Request so I want to change my script over to this method since it will eventually come under a heavy load. I added this to my perl.conf filePerlModule Apache::Request and apache says that it can not find the module in @INC (@INC contains: /etc/httpd/lib/perl /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl . /etc/httpd/) sure enough, I looked in there and it isn't. I went to the module list and the list claims that apache::request is included with the standard dist of mod perl. I'm running Apache 1.3.9 and mod_perl/1.24_01 What should I do? Also, I have a script that is running under apache::registry.I run the script by using a mod-actions handler that I have in my httpd.conf file like so.The script runs from a blank index.htm page and creates the dynamic output depending on the referring url and query-stringDirectory "/home/usr1/digital/membersurl/html/protected"> Apache::Request is not shipped with mod_perl ... Take a look at CPAN ... Or http://httpd.apache.org/apreq/ AddHandler RTS-protected-htm htm Action RTS-protected-htm /perl/content_manager/handler.pl /Directory> I imagine this is not very efficient? I guess I will eventually have to set it up as a hander? What is your opinion? Personnaly, I prefer a very simple handler, using ( owned ) libs, than a "script.pl", that much easy to maintains I'm new to packages and modules and have basically little experience with OOP. The script works fine with no errors, but I expect a heavy load in the future. I eventually want to have the correct solution but I'm trying to beat the learning curve before the traffic gets there. Can I set up the script now as a handler or does it have to be written in OO format? I do understand that a few things have to be changed, like I have to use apache::constants to finalize the handler phase. Reading several books and understanding more and more everyday. Any suggestions would be greatly appreciated. Thanks John Michael -- My mother always used to tell me, "The early bird gets the worm." The message seemed pretty clear to me: If you sleep late, you're a lot less likely to be killed by a bird. -- Elliott Downing
Re: Apache::Request UPLOAD_HOOK
OK. I get all that. Now I'm getting a very strange error when I try to use
the hook. the error from the error_log is: Undefined subroutine
Apache::Upload::handler called at /dev/null line 1.
Here is the code that calls the hook:
sub header_parser_handler($)
{
my $=shift;
my $hook_handler= sub {
my ($upload, $buf, $len, $hook_data)=@_;
$hook_cache-set($hook_data,$len);
Apache-log_error($hook_data: got $len bytes for .$upload-name);
};
my %cookies=Apache::Cookie-fetch;
my $u_id=$cookies{u_id}-value;
my
$q=Apache::Request-instance($r,TEMP_DIR=/home/www/spool,HOOK_DATA=$u_i
d,UPLOAD_HOOK=$hook_handler);
return OK;
}
Any idea what's going on here?
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: Joe Schaefer [EMAIL PROTECTED]
To: Issac Goldstand [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, October 08, 2001 19:16
Subject: Re: Apache::Request UPLOAD_HOOK
Issac Goldstand [EMAIL PROTECTED] writes:
The documentation on how to use this feature is a bit sketchy...
Yes, I agree. Doc patches are always welcome.
Comments below are from memory since I last tested this feature
about 6 months ago.
Can anyone explain: 1) What the variables passed to the callback
function are (looks like the Apache::Upload object is the first, but
what's been filled in there when the hook gets called?
The current upload object goes there when the hook is called.
The second looks like the current bunch of data that's been
recieved[?],
Right, it's the buffer from apache's ap_get_client_block,
which is usually around 2-4 KB. The hook runs before the
buffer gets written to the underlying tempfile, but as soon
as your hook has completed, Apache::Request will write it
automatically.
the third is the length, but is that the length recieved so far or the
length recieved between the last time it was called and this time?
The length of the buffer; the same as length($buffer).
And lastly, what can be placed in HOOK_DATA - scalar only?)
Yes, but the scalar can also be a ref to an array or hash.
2) Is there any way of knowing how often the hook will get called?
Not really- it's called when apache calls ap_get_client_block.
3) Is there a specific phase of the Request that Apache::Request
must be called and initialized with the callback before?
The hooks get run as the data is uploaded to the server,
which IOW is when the data is first being parsed. This
can happen at any phase you choose, but it only happens
once per request.
4) Are there any specific issues for using this with
Apache::Request-instance ?
Other than (3), I don't think so- but as I said before
this is not a well-tested feature (yet :)
HTH
--
Joe Schaefer
Re: Apache::Request UPLOAD_HOOK
Issac Goldstand [EMAIL PROTECTED] writes: The documentation on how to use this feature is a bit sketchy... Yes, I agree. Doc patches are always welcome. Comments below are from memory since I last tested this feature about 6 months ago. Can anyone explain: 1) What the variables passed to the callback function are (looks like the Apache::Upload object is the first, but what's been filled in there when the hook gets called? The current upload object goes there when the hook is called. The second looks like the current bunch of data that's been recieved[?], Right, it's the buffer from apache's ap_get_client_block, which is usually around 2-4 KB. The hook runs before the buffer gets written to the underlying tempfile, but as soon as your hook has completed, Apache::Request will write it automatically. the third is the length, but is that the length recieved so far or the length recieved between the last time it was called and this time? The length of the buffer; the same as length($buffer). And lastly, what can be placed in HOOK_DATA - scalar only?) Yes, but the scalar can also be a ref to an array or hash. 2) Is there any way of knowing how often the hook will get called? Not really- it's called when apache calls ap_get_client_block. 3) Is there a specific phase of the Request that Apache::Request must be called and initialized with the callback before? The hooks get run as the data is uploaded to the server, which IOW is when the data is first being parsed. This can happen at any phase you choose, but it only happens once per request. 4) Are there any specific issues for using this with Apache::Request-instance ? Other than (3), I don't think so- but as I said before this is not a well-tested feature (yet :) HTH -- Joe Schaefer
Re: Apache::Request cookie handling methods?
princepawn == princepawn [EMAIL PROTECTED] writes: princepawn Could someone point me to the documentation for princepawn apache-based cookie handling? perldoc Apache::Cookie Jon
Re: Apache::Request cookie handling methods?
[EMAIL PROTECTED] (princepawn) wrote: p.209 of the Eagle Book states that Apache::Request has some experimental cookie-handling functions. However, neither perldoc Apache or perldoc Apache::Request has the word cookie anywhere in their body. The cookie-handling stuff is called Apache::Cookie. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::Request cookie handling methods?
- Original Message - From: princepawn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 01, 2001 4:52 PM Subject: Apache::Request cookie handling methods? p.209 of the Eagle Book states that Apache::Request has some experimental cookie-handling functions. I don't believe they are experimental anymore. The Eagle book is growing a little oiutdated concerning some of the newer features of mod_perl. It's always good to check the mod_perl guide ( http://perl.apache.org/guide/ ), or other documentation on mod_perl too. However, neither perldoc Apache or perldoc Apache::Request has the word cookie anywhere in their body. CGI::cookie() is wonderful, but I feel funny using CGI.pm and CGI::Cookie under mod_perl and would much rather use Apache API methods. The cookie handlng functions from the Apache API come from the Apache::Cookie module. It has the same interface as CGI::Cookie, except that it requires you to pass it the request record too. It comes with the Apache::Request distribution, and is documented through `perldoc Apache::Cookie`. Per Einar Ellefsen
Re: Apache::Request
Hello, RHI get the following error on RHmy $i = Apache::Request-instance($r); RH RHCan't locate object method instance via package Apache::Request Just to avoid the whoops factor: make sure you have use Apache::Request in your script, too. This can also cause the error you are reporting. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Apache::Request
At 1:11 PM -0700 8/15/01, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); I think you want my $i = Apache::Request-new($r); I've never used or seen instance before, but I've only been doing mod_perl for about 20 months. Rob -- A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX.
Re: Apache::Request
I am reading the online docs... -r Robin Berjon wrote: On Wednesday 15 August 2001 22:11, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); Can't locate object method instance via package Apache::Request Why is that? Is the method not available? Are the docs outdated? Any comments welcomed... :) I am running mod_perl/1.22... Are you readiong the docs that come with 1.22 or some docs online (eg from search.cpan.org) ? $r-instance works fine here, but iirc it was introduced rather recently (though I could be wrong there). -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Machines take me by surprise with great frequency. -- Alan Turing
RE: Apache::Request
-Original Message- From: Robin Berjon To: [EMAIL PROTECTED] Sent: 8/15/01 4:39 PM Subject: Re: Apache::Request On Wednesday 15 August 2001 22:11, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); Can't locate object method instance via package Apache::Request Why is that? Is the method not available? Are the docs outdated? Any comments welcomed... :) I am running mod_perl/1.22... Are you readiong the docs that come with 1.22 or some docs online (eg from search.cpan.org) ? $r-instance works fine here, but iirc it was introduced rather recently (though I could be wrong there). instance showed up officially in libapreq 0.31_3 HTH --Geoff
RE: Apache::Request problem (possible bug)
this was fixed in cvs this past month. check out the archive of the
apreq-dev list (if there is one somewhere) to see the details. basically it
was because using param() to set a variable was calling Apache::Table-set,
which stringifies its arguments. Now it calls Apache::Table-add and does
some undef'ing, allowing you to set multiple values from a ref.
--Geoff
-Original Message--
From: Cees Hek
To: [EMAIL PROTECTED]
Sent: 4/6/01 11:07 AM
Subject: Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what
I'm
doing :)
Setting variables with $r-param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r-param('foo' = [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r-content_type('text/html');
$r-send_http_header();
my @list = $r-param('list');
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print "EOM";
HTML
BODY
list - $listBR
newlist - $newlistBR
BR
FORM
SELECT NAME="list" MULTIPLE
OPTIONBlue
OPTIONGreen
OPTIONRed
OPTIONYellow
/SELECT
INPUT TYPE="submit"
/FORM
/BODY
/HTML
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Apache::Request problem (possible bug)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 1:07 AM +1000 4/7/01, Cees Hek wrote:
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my @newlist = @{$r-param('newlist')};
What you stored was not an array, but a reference to an array.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
Now Writing - Technosocial buzz - http://commons.somewhere.com/buzz/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com
iQA/AwUBOs3IhyZsPfdw+r2CEQKJdgCggzcUkVZyshv0FlIon8adiDRqOIwAnRWv
EDOxp/nQOjVxPJRyhd/BydE3
=Eyiy
-END PGP SIGNATURE-
Re: Apache::Request param() problem?
"James Sheridan-Peters" [EMAIL PROTECTED] writes:
Quick summary:
Pulling parameters from a POST method using Apache::Request, largely to make
it easier to deal with multiple value variables. The problem occurs if I
have two variables, differentiated only by case (eg. wanthelp=something
and wantHelp=somethingelse).
Given the about pseudo-values, when using apr-param('wanthelp') OR
apr-param('wantHelp') I get the same response, namely an array of two
values something and somethingelse for each.
Unfortunately, I have no control over what the variable names will be nor
how many parameters they will have, so I must handle all possible cases. Am
I missing some parameter to make this case-sensitive? Is there a better way
to do this than using Apache::Request?
Apache::Request parses the request data into apache tables, which
by nature use case-insensitive keys. I'm afraid you're SOL if you
need to differentiate case-sensitive parameter keys like "wantHelp" and
"wanthelp" with the current implementation of libapreq/Apache::Request.
Probably CGI is your best bet for now- but you could submit a request/bug
report to the apreq list at
[EMAIL PROTECTED]
HTH.
--
Joe Schaefer
Re: Apache::Request and redirects
On Sat, 30 Dec 2000, Matt Sergeant wrote:
Another minor issue is that Apache::Request is not trivially subclassed,
the returned value from $self-SUPER::new() must be reblessed into the
desired class.
Thats a pretty standard perl idiom:
sub new {
my $class = shift;
my $self = $class-SUPER::new;
bless $self, $class;
}
Well, a package is generally expected to bless its objects into the value
of $class, not the value of __PACKAGE__. You shouldn't have to override
the constructor simply to rebless the object.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Apache::Request Under Win32?
On Tue, 28 Nov 2000, Ryan Adams wrote: Excuse me if this is a ridiculous question, but is there any way to install Apache::Request on a Windows box without VC++? [ ... ] Hi, No - it requires a C compiler ... Even with VC++, though, some changes to the distribution are needed to get it to compile; if you're interested, drop me a note off-line, and I'll send you the patches I used. However, if you're just interested in trying it out, I made up a libapreq ppm package for use with ActivePerl (builds 6xx) - you can get it from http://theoryx5.uwinnipeg.ca/ppmpackages/ best regards, randy kobes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Request-new() problem
On Tue, Sep 26, 2000 at 01:06:33PM -0400, Geoffrey Young wrote: mod_perl wasn't built with EVERYTHING=1 (I'm not sure whether libapreq needs PERL_TABLE_API=1 or not) In fact I needed to rebuild mod_perl with this enabled in order to have Apache::Request works properly. -- Ciao, Maurizio.
Re: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, John Reid wrote: Hi guys Has anyone any experience of passing a 0 as a parameter value through Apache::Request. I am passing a QUERY_STRING like ?param1=value1param2=0param3=value3. It appears that the 0 is being interpretted as an empty string. Is this a bug/expected behaviour or am I looking in completely the wrong area for the source of the problem? No its a bug. It also occurs if the QUERY_STRING is just 0 on its own. -- Matt/ ** Director and CTO ** ** AxKit.com Ltd ** ** XML Application Serving ** ** http://axkit.org ** ** XSLT, XPathScript, XSP ** ** Personal Web Site: http://sergeant.org/ **
Re: Apache::Request and parameters = 0
Matt Sergeant wrote: On Thu, 5 Oct 2000, John Reid wrote: Hi guys Has anyone any experience of passing a 0 as a parameter value through Apache::Request. I am passing a QUERY_STRING like ?param1=value1param2=0param3=value3. It appears that the 0 is being interpretted as an empty string. Is this a bug/expected behaviour or am I looking in completely the wrong area for the source of the problem? No its a bug. It also occurs if the QUERY_STRING is just 0 on its own. -- Matt/ ** Director and CTO ** ** AxKit.com Ltd ** ** XML Application Serving ** ** http://axkit.org ** ** XSLT, XPathScript, XSP ** ** Personal Web Site: http://sergeant.org/ ** In my limited experience, it is Perl in general that treats the value 0, in a query string as the empty string. In all of the scripts I have written, if 0 is possible as a param value, I have to explicity check for 0. In essence I agree with Matt, but wanted to pop that little piece of information in there in case it turns out to be pertinent... --Dana
Re: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, Dana C. Chandler III wrote:
In my limited experience, it is Perl in general that treats the value 0,
in a query string as the empty string. In all of the scripts I have
written, if 0 is possible as a param value, I have to explicity check
for 0.
This is only the case when you're going:
if ($r-param('name')) {
# do something
}
if its a zero then you should expect to be bitten in the ass by that
one. However I do assume that there's similar code going on somewhere to
turn the zero into undef.
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
Re: Apache::Request and parameters = 0
Matt Sergeant wrote:
On Thu, 5 Oct 2000, Dana C. Chandler III wrote:
In my limited experience, it is Perl in general that treats the value 0,
in a query string as the empty string. In all of the scripts I have
written, if 0 is possible as a param value, I have to explicity check
for 0.
This is only the case when you're going:
if ($r-param('name')) {
# do something
}
if its a zero then you should expect to be bitten in the ass by that
one. However I do assume that there's similar code going on somewhere to
turn the zero into undef.
Just to add, I was explicitly checking for 0 in the value returned but
was getting an empty string. 0 in this case was a single character
required. An empty string was not.
Once Matt informed me it was a bug/feature it set my mind at ease and I
was able to implement a work around.
--
John Reid
Senior Analyst/Programmer
Open Connect (Ireland) Ltd
http://www.openconnect.ie/
Re: Apache::Request and parameters = 0
Matt Sergeant wrote:
On Thu, 5 Oct 2000, Dana C. Chandler III wrote:
In my limited experience, it is Perl in general that treats the value 0,
in a query string as the empty string. In all of the scripts I have
written, if 0 is possible as a param value, I have to explicity check
for 0.
This is only the case when you're going:
if ($r-param('name')) {
# do something
}
if its a zero then you should expect to be bitten in the ass by that
one. However I do assume that there's similar code going on somewhere to
turn the zero into undef.
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
Yes, in particular,
$value = $r-param('name') || "";
this little snipit of code will bite you if the param is 0.
I should have been more specific.
--Dana
Re: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, Dana C. Chandler III wrote:
Yes, in particular,
$value = $r-param('name') || "";
Or worse, $r-param('name') || "3"; # default but true
Even I'm guilty of that one sometimes :-)
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request and parameters = 0
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 9:57 AM
To: Dana C. Chandler III
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, Dana C. Chandler III wrote:
Yes, in particular,
$value = $r-param('name') || "";
Or worse, $r-param('name') || "3"; # default but true
Even I'm guilty of that one sometimes :-)
well, I suppose we are all guilty of that one... perl hubris to the extreme
:)
however, just for clarity, I don't see how this is a bug in Apache::Request
(as you originally pointed out)...
#!/usr/bin/perl
use Apache::Request;
my $r = Apache::Request-new(shift);
my $value = $r-param('foo');
$r-send_http_header('text/plain');
print "foo: $value\n";
print "foo is undefined" unless defined $value;
/perl-bin/foo.pl?foo=0 produces:
foo: 0
which doesn't look like a bug to me.
--Geoff
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, Geoffrey Young wrote:
however, just for clarity, I don't see how this is a bug in Apache::Request
(as you originally pointed out)...
#!/usr/bin/perl
use Apache::Request;
my $r = Apache::Request-new(shift);
my $value = $r-param('foo');
$r-send_http_header('text/plain');
print "foo: $value\n";
print "foo is undefined" unless defined $value;
/perl-bin/foo.pl?foo=0 produces:
foo: 0
which doesn't look like a bug to me.
You're right... I was remembering something else:
package FooTest;
use Apache::Constants;
use Apache::Reload;
sub handler {
my $r = shift;
$r-send_http_header;
print "Args: ", scalar $r-args, "\n";
return OK;
}
1;
Now send a request with the querystring 0 to that handler. I get:
Args:
No zero. $ENV{QUERY_STRING} contains the zero though.
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request and parameters = 0
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 10:26 AM
To: Geoffrey Young
Cc: Dana C. Chandler III; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Apache::Request and parameters = 0
[snip]
You're right... I was remembering something else:
package FooTest;
use Apache::Constants;
use Apache::Reload;
sub handler {
my $r = shift;
$r-send_http_header;
print "Args: ", scalar $r-args, "\n";
return OK;
}
1;
Now send a request with the querystring 0 to that handler. I get:
Args:
No zero. $ENV{QUERY_STRING} contains the zero though.
ok, I see that. Apache::Request seems to handle that condition fine,
though.
Something to keep in mind...
--Geoff
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request and parameters = 0
On Thu, 5 Oct 2000, Geoffrey Young wrote:
package FooTest;
use Apache::Constants;
use Apache::Reload;
sub handler {
my $r = shift;
$r-send_http_header;
print "Args: ", scalar $r-args, "\n";
return OK;
}
1;
Now send a request with the querystring 0 to that handler. I get:
Args:
No zero. $ENV{QUERY_STRING} contains the zero though.
ok, I see that. Apache::Request seems to handle that condition fine,
though.
I'm not sure I understand you since Apache::Request is just a subclass of
Apache, it does exactly the same thing:
use Apache::Request;
sub handler {
my $r = Apache::Request-new(shift);
$r-send_http_header;
print "Args: ", scalar $r-args, "\n";
return OK;
}
Outputs the same result.
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request and parameters = 0
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 10:53 AM
To: Geoffrey Young
Cc: Dana C. Chandler III; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Apache::Request and parameters = 0
[snip]
ok, I see that. Apache::Request seems to handle that
condition fine,
though.
I'm not sure I understand you since Apache::Request is just a
subclass of
Apache, it does exactly the same thing:
use Apache::Request;
sub handler {
my $r = Apache::Request-new(shift);
$r-send_http_header;
print "Args: ", scalar $r-args, "\n";
return OK;
}
Outputs the same result.
oh, sorry... I meant using Apache::Request methods, like
my @values = $r-param;
--
Matt/
** Director and CTO **
** AxKit.com Ltd ** ** XML Application Serving **
** http://axkit.org ** ** XSLT, XPathScript, XSP **
** Personal Web Site: http://sergeant.org/ **
RE: Apache::Request-new() problem
On Tue, 26 Sep 2000, Herrington, Jack wrote: I'm using Mason in process with mod_perl. I have also tried using mod_perl handlers direct with Apache::Request with no success. what do you see if you configure Apache::Status and open the url: /perl-status?Apache::Request ? also, any difference if you change Apache/Request.pm from: __PACKAGE__-mod_perl::boot($VERSION); to: DynaLoader::bootstrap(__PACKAGE__, $VERSION); ?
Re: Apache-request($r) broken?
On Thu, 24 Aug 2000, Ken Williams wrote:
Hi all,
It looks like setting Apache-request($r) doesn't work as documented. I
can't get it to install a subclass of Apache as the request object.
Here's some code in a handler:
_
warn "blessing $r into ", __PACKAGE__;
Apache-request($r = bless { _r = $r});
warn "\$r is $r";
warn "Apache-request is ", Apache-request;
_
And the result in the error logs:
_
blessing Apache=SCALAR(0x1401eaeb8) into Apache::Filter at ...
$r is Apache::Filter=HASH(0x140088028) at ...
Apache-request is Apache=SCALAR(0x1401fdab8) at ...
_
Notice that even after I call Apache-request($r), Apache-request still
returns an object blessed into the 'Apache' class, not the class of the
object I gave it.
it is broken in this respect, i just added this to ToDo:
- Apache-request($r) digs the request_rec out of $r regardless of the
type/class, e.g. Apache-request(bless {r = $r}, 'My::Apache')
with your PerlRun patch applied, your in no rush to have this fixed,
right?
RE: Apache::Request-new() problem
-Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Monday, September 25, 2000 10:36 PM To: [EMAIL PROTECTED] Subject: Apache::Request-new() problem I have the same problem as one of the previous reporters with Apache::Request-new(). The problem occurs whether I call it after a 'use' or after a 'PerlModule' load. Perl returns the no 'new' method could be found for Apache::Request. My setup is: Apache 1.3.12 mod_perl 1.24 Perl 6.5 Redhat 6.2 libapreq 0.31 Both Apache::Request and Apache::Cookie exhibit the same symptoms, and simply running this Perl script: use Apache::Request; my $apr = Apache::Request-new( $r ); Gives exactly the same response (as opposed to complaining about the unititliazed $r). Is there anywhere I can locate the original Apache::Request all-Perl code? well, if you don't have that, then you likely don't have Apache::Request or Apache::Cookie - they aren't part of the mod_perl distribution :) you need libapreq, which can be found under the Apache tree on CPAN HTH --Geoff Jack Herrington Engineering Manager Certive - Building the world's first broadband B2B network (650) 701-8809
RE: Apache::Request-new() problem
well, if you don't have that, then you likely don't have Apache::Request or Apache::Cookie - they aren't part of the mod_perl distribution :) you need libapreq, which can be found under the Apache tree on CPAN libapreq appears to come with Bundle::Apache, but I also downloaded it seperately and installed it directly. My thinking is that the XS code isn't working with Perl 5.6. There are other XS based libraries that are working (like MD5), but this one refuses to work.
RE: Apache::Request-new() problem
-Original Message- From: Herrington, Jack [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 26, 2000 12:17 PM To: [EMAIL PROTECTED] Subject: RE: Apache::Request-new() problem well, if you don't have that, then you likely don't have Apache::Request or Apache::Cookie - they aren't part of the mod_perl distribution :) you need libapreq, which can be found under the Apache tree on CPAN libapreq appears to come with Bundle::Apache, but I also downloaded it seperately and installed it directly. oh, ok... if running from Registry, try this: #!/usr/bin/perl use strict; use Apache::Request; my $apr = Apache::Request-new(shift); if that fails, start checking the usual suspects: libapreq was built, but not actually installed in perl's @INC mod_perl wasn't built with EVERYTHING=1 (I'm not sure whether libapreq needs PERL_TABLE_API=1 or not) those ought to help some... if that fails, send the exact script, OS, build options, actual error messages, etc... My thinking is that the XS code isn't working with Perl 5.6. I have it working with 5.6 on linux just fine... There are other XS based libraries that are working (like MD5), but this one refuses to work. HTH --Geoff
Re: Apache::Request-new() problem
On Mon, 25 Sep 2000, Herrington, Jack wrote:
I have the same problem as one of the previous reporters with
Apache::Request-new(). The problem occurs whether I call it after a 'use'
or after a 'PerlModule' load. Perl returns the no 'new' method could be
found for Apache::Request.
sounds to me like your script is not running under mod_perl.
Apache/Request.pm calls this to bootstrap the xs interface:
__PACKAGE__-mod_perl::boot($VERSION);
if you are not running under mod_perl ($ENV{MOD_PERL} is not set), then
the interface is not bootstrapped. this is done so 'perl -c' can be run
on scripts that 'use Apache::*' with apis only available when running
inside the server.
RE: Apache::Request-new() problem
I'm using Mason in process with mod_perl. I have also tried using mod_perl
handlers direct with Apache::Request with no success.
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 10:23 AM
To: Herrington, Jack
Cc: [EMAIL PROTECTED]
Subject: Re: Apache::Request-new() problem
On Mon, 25 Sep 2000, Herrington, Jack wrote:
I have the same problem as one of the previous reporters with
Apache::Request-new(). The problem occurs whether I call it after a
'use'
or after a 'PerlModule' load. Perl returns the no 'new' method could be
found for Apache::Request.
sounds to me like your script is not running under mod_perl.
Apache/Request.pm calls this to bootstrap the xs interface:
__PACKAGE__-mod_perl::boot($VERSION);
if you are not running under mod_perl ($ENV{MOD_PERL} is not set), then
the interface is not bootstrapped. this is done so 'perl -c' can be run
on scripts that 'use Apache::*' with apis only available when running
inside the server.
Re: Apache::Request server error??
On Mon, 25 Sep 2000, Sophokles Zafeiris wrote: I' m trying to run the file_upload.pl. script, that can be found in the eg directory of the Apache::Request source file. I've installed the Apache::Request but I get the following server error : Can't locate object method "new" via package "Apache::Request" at /export/home0/www/cgi-bin/file_upload.pl.cgi line 8. Can anyone help me?? The most obvious mistake is that you haven't 'use'd or 'PerlModule'd Apache::Request. This will often result in the above kind of error. MBM -- Tell me, O Octopus, I begs, / Is those things arms, or is they legs? / I marvel at thee, Octopus; / If I were thou, I'd call me us. -- Ogden Nash
Re: Apache::Request::upload
At 10:04 AM 7/14/00 -0600, Dave Thomas wrote:
Hello,
Question: Why does the Apache::Request object not return an Upload
object when
there was a file sent.
Backgroud: I have pulled the sample script from the Apache::Request
distribution and
used that in my handler, this instance works fine. When I try to use it
incorporated
with the object model developed here it closes up shop and goes home.
I initialize the Apache::Request object in an init function from the
handler. This is then
used to display the templated html content with
$apr-send_http_header('text/html');
at its top. I've made certain that the Request object's address remains
the same
throughout this process. When I fill in the file field and submit the
first thing that the
script does after initializing the Request object is try to initialize
the Upload object, this
fails miserably with a return value of undef.
Most likely you're missing a
ENCTYPE="multipart/form-data"
in your FORM tag.
Hope this helps
Tobias
Re: Apache::Request::upload
The template contains the ENCTYPE="multipart/form-data",
uses METHOD="POST", and the action is my handler.
I initialize the object with:
my $r = 'Apache'-request();
my $apr = 'Apache::Request'-new($r);
From within my local CGI class I get the Apache::Request class reference
from
the passed hash ref and set up the meta-data:
$self-{_ApacheRequest} = $args-{ApacheRequest};
This line always returns undef (but it works with the example program):
$self-{_ApacheRequestUpload} = $self-{_ApacheRequest}-upload;
I have also tried in the init object:
my $upload = $apr-upload;
Thank you,
Dave
Tobias Hoellrich wrote:
At 10:04 AM 7/14/00 -0600, Dave Thomas wrote:
Hello,
Question: Why does the Apache::Request object not return an Upload
object when
there was a file sent.
Backgroud: I have pulled the sample script from the Apache::Request
distribution and
used that in my handler, this instance works fine. When I try to use it
incorporated
with the object model developed here it closes up shop and goes home.
I initialize the Apache::Request object in an init function from the
handler. This is then
used to display the templated html content with
$apr-send_http_header('text/html');
at its top. I've made certain that the Request object's address remains
the same
throughout this process. When I fill in the file field and submit the
first thing that the
script does after initializing the Request object is try to initialize
the Upload object, this
fails miserably with a return value of undef.
Most likely you're missing a
ENCTYPE="multipart/form-data"
in your FORM tag.
Hope this helps
Tobias
Re: Apache::Request and memory
Okay, I think I tracked this down to a one-byte buffer overflow.
Try the attached patch to see if that fixes it (it fixes things
in my testing).
Unfortunately, the overflow seemed to sneak through with no problems
on FreeBSD, and on Linux if you compile with -g.
Jim
On Jun 24, dorian wrote:
breaks for me too. null byte issue maybe? i don't know. i can't write c. :)
.djt
diff -ur libapreq-0.31-orig/c/apache_request.c libapreq-0.31/c/apache_request.c
--- libapreq-0.31-orig/c/apache_request.c Fri Jul 2 18:00:17 1999
+++ libapreq-0.31/c/apache_request.cSat Jun 24 16:23:06 2000
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req-parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req-parms, param, value);
continue;
}
ap_table_add(req-parms, param, filename);
@@ -424,7 +425,7 @@
upload-filename = ap_pstrdup(req-r-pool, filename);
upload-name = ap_pstrdup(req-r-pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload-size += fwrite(buff, 1, blen, upload-fp);
}
diff -ur libapreq-0.31-orig/c/multipart_buffer.c libapreq-0.31/c/multipart_buffer.c
--- libapreq-0.31-orig/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31/c/multipart_buffer.c Sat Jun 24 16:23:25 2000
@@ -57,271 +57,283 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first little = littleend) {
-return big;
-}
-if (bigend - big littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen len ? needlen : len) == 0
+(partial || len = needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big = bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s = littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self-bytes_in_buffer 0 self-buf_begin != self-buffer)
+memmove(self-buffer, self-buf_begin, self-bytes_in_buffer);
+ self-buf_begin = self-buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = FILLUNIT - self-bytes_in_buffer - 1;
+
+ /* read the required number of bytes */
+ if(bytes_to_read 0)
+{
+ char *buf = self-buffer + self-bytes_in_buffer;
+ ap_hard_timeout("[libapreq] multipart_buffer.c:fill_buffer", self-r);
+ actual_read = ap_get_client_block(self-r, buf, bytes_to_read);
+ ap_kill_timeout(self-r);
+
+ /* update the buffer length */
+ if(actual_read 0)
+ self-bytes_in_buffer += actual_read;
}
-return NULL;
-}
+
+ return actual_read;
+}
/*
- *
Re: Apache::Request and memory
...Problem with patch to fix memory blow-out with file uploads... Okay, I think I tracked this down to a one-byte buffer overflow. Try the attached patch to see if that fixes it (it fixes things in my testing). Thanks--certainly an improvement. I tried a 25k file, which worked fine. However a 1.8MB file still caused a segfault. If you can't replicate the problem, let me know what diagnostics you'd like me to run. I'm not familiar with gdb, so I'm not sure where to start. Unfortunately, the overflow seemed to sneak through with no problems on FreeBSD, and on Linux if you compile with -g. I'm running latest Apache, mod_perl, and Perl, under Linux (2.2 kernel). PS: Can anyone point me to a tutorial on debugging XS modules? From time to time Doug provides some magic gdb commands which are really helpful--I'd love to be able to do this kind of stuff myself... -- Jeremy Howard [EMAIL PROTECTED]
Re: Apache::Request and memory
Okay, I think I tracked this down to a one-byte buffer overflow. Try the attached patch to see if that fixes it (it fixes things in my testing). Oops. Please ignore my last message. Your fix works just fine... I had some code to automatically kill my process after it got an upload 1MB, in order to work around the libapreq bug that your patch fixed! -- Jeremy Howard [EMAIL PROTECTED]
Re: Apache::Request and memory
On Thu, 22 Jun 2000, Jim Winstead wrote: Attached is a patch to libapreq that addresses this problem. Question for Doug, Can we get libapreq 0.32 out any time soon? There are some pretty nasty bugs in 0.31 that I'm waiting to get fixed. (the null cookies problem, this problem, the form charset problem...) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Apache::Request and memory
Apache::Request eats up memory during a file upload Attached is a patch to libapreq that addresses this problem. ... Thanks for this, Jim. Unfortunately, I'm having some problems with the patch. When I try and upload a file greater than a couple of k, I get a segfault in httpd. Could you possibly email me your current working libapreq sources?--perhaps there's some other differences hiding somewhere... Has anyone applied this patch and got it working with large uploads? -- Jeremy Howard [EMAIL PROTECTED]
Re: Apache::Request and memory
Attached is a patch to libapreq that addresses this problem.
(Doug, this may be updated since we last sent you this patch to
resolve issues with IE 4.5 on the Mac, which doesn't terminate the
MIME boundary correctly when there are input type=image fields
in a multipart/form-data form.)
Jim
On Jun 21, dorian wrote:
Reply-To:
hm, i guess my post didn't seem to go through.
in regards to the handling of file uploads with Apache::Request -
i noticed that per file uploaded, the apache process grew approximately by the size
of the file uploaded and stayed that way. could someone possibly point me into the
direction that would help me deallocate this memory?
thanks
.djt
diff -ruN libapreq-0.31/c/apache_request.c libapreq-0.31-new/c/apache_request.c
--- libapreq-0.31/c/apache_request.cFri Jul 2 18:00:17 1999
+++ libapreq-0.31-new/c/apache_request.cTue May 30 12:06:42 2000
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req-parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req-parms, param, value);
continue;
}
ap_table_add(req-parms, param, filename);
@@ -424,7 +425,7 @@
upload-filename = ap_pstrdup(req-r-pool, filename);
upload-name = ap_pstrdup(req-r-pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload-size += fwrite(buff, 1, blen, upload-fp);
}
diff -ruN libapreq-0.31/c/multipart_buffer.c libapreq-0.31-new/c/multipart_buffer.c
--- libapreq-0.31/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31-new/c/multipart_buffer.c Tue May 30 12:35:58 2000
@@ -57,271 +57,283 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first little = littleend) {
-return big;
-}
-if (bigend - big littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen len ? needlen : len) == 0
+(partial || len = needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big = bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s = littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self-bytes_in_buffer 0 self-buf_begin != self-buffer)
+memmove(self-buffer, self-buf_begin, self-bytes_in_buffer);
+ self-buf_begin = self-buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = FILLUNIT - self-bytes_in_buffer;
+
+ /* read the required number of bytes */
+ if(bytes_to_read 0)
+{
+ char *buf = self-buffer + self-bytes_in_buffer;
+ ap_hard_timeout("[libapreq]
Re: Apache::Request-new($r) does NOT work, why?
At 02:04 PM 4/30/00 -0400, Sam Carleton wrote: Tobias, The new is blowing up on me. This is the error message: null: Can't locate object method "new" via package "Apache::Request" Try installing it :-) $ perl -MCPAN -e shell cpan install Apache::Request Tobias PS: Please, please read the guide at http://perl.apache.org/- everything is in there. If you schedule is too tight to read the guide, rethink your schedule.
Re: detecting fd leaks (was Re: Apache::Request)
On Thu, 13 Apr 2000, Stas Bekman wrote: I have no real conclusion to reach, except that it seems to be leaking files. Well, I wanted to write Apache::FileLeak or an extension to Apache::VMonitor to show the opened file descriptors, the files and the processes that have opened them, but this requires a root access unless you want to see the information about the current process only. what i've found to be a nice solution for such a problem, is to use PlRPC, where the server is setuid root. access is limited to 127.0.0.1, which might not be enough, but is perfect for something like Audio-RaveMP (on cpan), it might also be a reasonable solution for your Apache::FileLeak.
Re: detecting fd leaks (was Re: Apache::Request)
On Thu, 20 Apr 2000, Doug MacEachern wrote: On Thu, 13 Apr 2000, Stas Bekman wrote: I have no real conclusion to reach, except that it seems to be leaking files. Well, I wanted to write Apache::FileLeak or an extension to Apache::VMonitor to show the opened file descriptors, the files and the processes that have opened them, but this requires a root access unless you want to see the information about the current process only. what i've found to be a nice solution for such a problem, is to use PlRPC, where the server is setuid root. access is limited to 127.0.0.1, which might not be enough, but is perfect for something like Audio-RaveMP (on cpan), it might also be a reasonable solution for your Apache::FileLeak. Wow, looks like a nice toy^H^H^Htool :) I'll try it. Thanks, Doug! __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Apache::Request
Ok. So I've installed lsof, although I'm a little unclear on how to use it. Right now I'm pretty brute force. Here's what I execute: lsof | grep httpd | grep myuser | wc -l This (hopefully) gives me the number of files that my httpd children (owner "myuser") have open. When I first file up apache with my code loaded, it is 171. Then I start submitting requests, posting a single file to Apache::Request with each POST. Here's how the count changes with each request: 171 (starting point) 215 225 235 245 255 265 266 267 268 269 270 I have no real conclusion to reach, except that it seems to be leaking files. I then ran the same test on a server that had received a couple hundred files over it's lifespan. It was at 1472. It was giving me the following error on every new POST: [Thu Apr 13 01:06:12 2000] [error] [Thu Apr 13 01:06:12 2000] null: fdopen failed! at /usr/local/apache/notifi/perl/Handler/SubmitHandler.pm line 285, _GEN_243 chunk 15. That line of code (line 285): "$blockFile = $nextBlock-fh()". It asks the upload block for it's filehandle. Anyway, short of using some of the other MIME parsing modules to do the content parse myself, does anyone else have some suggestions? Unless Apache isn't respecting the Apache::Request request to free the filehandles when the pool is destroyed (or unless the pool is never destroyed!) I don't see how the files aren't going away. Thanks for the advice so far! If you have better instructions for using lsof, I'd also appreciate that! -jse From: Doug MacEachern [EMAIL PROTECTED] Date: Wed, 12 Apr 2000 22:48:06 -0700 (PDT) To: "John S. Evans" [EMAIL PROTECTED] Cc: modperl [EMAIL PROTECTED] Subject: Re: Apache::Request On Tue, 11 Apr 2000, John S. Evans wrote: I'm using Solaris (SunOS 5.7, according to uname). The number of files varies, and I can control this if I know what the limits are. Is the 256 limit per process or for the entire machine? For instance, if I have 10 apache children going full bore, is the practical limit 25 per child, or 256 per child? i think it's per-child. I saw (in the code) that there's one open file per uploaded file. That should be fine. I just need to find out if they're getting closed correctly. What is "lsof"? look it up on freshmeat.net, it'll show you what files the process has open. should be useful to see if any files are not being closed.
detecting fd leaks (was Re: Apache::Request)
I have no real conclusion to reach, except that it seems to be leaking files. Well, I wanted to write Apache::FileLeak or an extension to Apache::VMonitor to show the opened file descriptors, the files and the processes that have opened them, but this requires a root access unless you want to see the information about the current process only. The other problem is that I couldn't find a generic cross platform library, that provides this kind of information. I've suggested to have a hook in the parent process that will be able to deliver this only root accessible information to a non-root child. Just like the information about apache processes can be retrieved by any child thru mod_status or Apache::VMonitor (Apache::Scoreboard). On linux I'd retrieve the information about opened fds by reading /proc/PID/fd directory, probably it's the same on every OS that supports proc fs. So the two problems to be solved are: 1) finding a generic solution to retrieve the fd info as root 2) making this information available to the child processes Ideas? __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide/ mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Apache::Request
I'm using Solaris (SunOS 5.7, according to uname). The number of files varies, and I can control this if I know what the limits are. Is the 256 limit per process or for the entire machine? For instance, if I have 10 apache children going full bore, is the practical limit 25 per child, or 256 per child? I saw (in the code) that there's one open file per uploaded file. That should be fine. I just need to find out if they're getting closed correctly. What is "lsof"? Thanks! -jse From: Doug MacEachern [EMAIL PROTECTED] Date: Tue, 11 Apr 2000 21:26:19 -0700 (PDT) To: "John S. Evans" [EMAIL PROTECTED] Cc: modperl [EMAIL PROTECTED] Subject: Re: Apache::Request On Mon, 10 Apr 2000, John S. Evans wrote: I'm looking for some help/advice with Apache::Request. I'm currently using Apache::Request to parse the POST that is used to upload a bunch of files to our server. how many files? what os are you using? solaris has a 256 limit. The problem I'm running into is that I seem to be running out of file descriptors over a long period of time, if a large number of files (between 50 and 200) are posted at once. there will be an open FILE* for each file uploaded in a given request, none of which are closed until the request is over. try using lsof to see if any of them are not being closed after the request is done.
Re: Apache::Request
On Tue, Apr 11, 2000 at 11:52:44PM -0700, John S. Evans wrote: I saw (in the code) that there's one open file per uploaded file. That should be fine. I just need to find out if they're getting closed correctly. What is "lsof"? 'LiSt Open Files', its really a handy tool for diagnosing. I just happened to be setting up a new machine today and checked for the latest release to grab and install. Its available at 'ftp://vic.cc.purdue.edu/pub/tools/unix/lsof'. -- The results of your IQ test are back, they're negative. Mike Hall, Unix Admin - Rock Island Communications [EMAIL PROTECTED] System Admin - riverside.org[EMAIL PROTECTED]
Re: Apache::Request
On Tue, 11 Apr 2000, John S. Evans wrote: I'm using Solaris (SunOS 5.7, according to uname). The number of files varies, and I can control this if I know what the limits are. Is the 256 limit per process or for the entire machine? For instance, if I have 10 apache children going full bore, is the practical limit 25 per child, or 256 per child? i think it's per-child. I saw (in the code) that there's one open file per uploaded file. That should be fine. I just need to find out if they're getting closed correctly. What is "lsof"? look it up on freshmeat.net, it'll show you what files the process has open. should be useful to see if any files are not being closed.
Re: Apache::Request
On Mon, 10 Apr 2000, John S. Evans wrote: I'm looking for some help/advice with Apache::Request. I'm currently using Apache::Request to parse the POST that is used to upload a bunch of files to our server. how many files? what os are you using? solaris has a 256 limit. The problem I'm running into is that I seem to be running out of file descriptors over a long period of time, if a large number of files (between 50 and 200) are posted at once. there will be an open FILE* for each file uploaded in a given request, none of which are closed until the request is over. try using lsof to see if any of them are not being closed after the request is done.
Re: Apache::Request weirdness
Ilya Obshadko wrote: Hello, I've discovered the following. Suggest that you use Apache::Request object in both fixup handler and registry script. So we have: 1) unpredictable segmentation faults I had the same problem. I think there must be some problems in libapreq (which Apache::Request uses). I was in a hurry when I ran into the problem, so I just coded around it by writing Perl equivalents of the functions I needed from Apache::Request. Eventually (in my copious spare time), I'll take some time and see if I can scrounge through a core dump to see what's going on. 2) when parsing POST data, only first-time call (in fixup handler) produces correct results, the other one returns crap. You'll get this behavior whether you're getting the POST data from Apache::Request, or just the request object's content() call. The problem is that the C API call that these functions use (ap_read_client_block, I believe) can only be called once per request. The way I've gotten around this limitation is to parse all the GET and POST data into a hash reference in the first handler, and then use the $r-pnotes method to pass the parameters from handler to handler (If you're addicted to CGI.pm, you can use the hash reference as the argument to CGI-new in your content handler and get the same results as if CGI handled the parameter parsing itself.) Good luck, -- Kevin | "Though there are ... few restrictions on the vote nowadays ... Murphy | some standards are still upheld ... at last report, the votes | from the entire God-forsaken state of Texas are still thrown, | uncounted and burning, into the River Charles." - T.H. Zweibel
