Re: Apache::Request->instance(undef)
Dave Rolsky <[EMAIL PROTECTED]> writes:
> If you call Apache::Request->instance with an undefined value, it dies
> when it tries to call pnotes() on that argument.
>
> It seems to me that it should simply return a false value if given
> undef. This can happen if you have a piece of code like this:
>
> my $r = Apache::Request->instance(Apache->request);
>
> which may be called during server startup or during a request.
Would something like this be ok?
sub instance {
my ($class, $r) = @_;
return undef unless defined $r;
if (my $apreq = $r->pnotes('apreq')) {
return $apreq;
}
my $new_req = $class->new($r, @_);
$r->pnotes('apreq', $new_req);
return $new_req;
}
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::Cookie
"Swen Schillig" <[EMAIL PROTECTED]> writes: > Hi * > > I have a problem with Apache::Cookie setting the > expiration value correctly. > Meaning whatever I specify, the default value is used instead ( which > is now or -1) ! [...] > Am I doing something wrong or is this a known bug ?? Bug, previously unknown. > Any help ? It looks to me like there may be a problem in apreq_cookie.c (it may not be computing the "expires" date correctly for Netscape cookies). Which version of libapr are you using? -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::Cookie
Joe Schaefer <[EMAIL PROTECTED]> writes: > It looks to me like there may be a problem in apreq_cookie.c > (it may not be computing the "expires" date correctly for Netscape > cookies). Which version of libapr are you using? If you're using the latest libapr, this patch to libapreq2 should fix the problem. Index: src/apreq_cookie.c === RCS file: /home/cvs/httpd-apreq-2/src/apreq_cookie.c,v retrieving revision 1.20 diff -u -r1.20 apreq_cookie.c --- src/apreq_cookie.c 26 Sep 2003 13:58:33 - 1.20 +++ src/apreq_cookie.c 18 Dec 2003 04:57:37 - @@ -89,7 +89,7 @@ if (!strcasecmp(time_str, "now")) c->max_age = 0; else -c->max_age = apreq_atoi64t(time_str); +c->max_age = apr_time_from_sec(apreq_atoi64t(time_str)); } static int has_rfc_cookie(void *ctx, const char *key, const char *val) @@ -478,7 +478,7 @@ return apr_snprintf(buf, len, format, c->v.name, c->v.data, c->version, NULL2EMPTY(c->path), NULL2EMPTY(c->domain), NULL2EMPTY(c->port), NULL2EMPTY(c->comment), -NULL2EMPTY(c->commentURL), c->max_age); + NULL2EMPTY(c->commentURL), apr_time_sec(c->max_age)); } -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::Cookie
"Swen Schillig" <[EMAIL PROTECTED]> writes: > Joe > > Thanks for the patch the expiration is working fine now > even though the test fails :-) > > > t/testall -v > All APREQ Tests: > Cookie: ..F. > Param:... > Parsers: .. > > 9 tests run: 8 passed, 1 failed, 0 not implemented. > > Failed tests in Cookie: > 1) netscape_cookie: expected > > > foo=bar; path=/quux; domain=example.com; expires=Thu, 18-Dec-2003 11:51:26 > GMT > < > but saw > > > foo=bar; path=/quux; domain=example.com; expires=Fri, 17-Dec-2004 11:50:55 > GMT > < The failure shows that apreq_expires is broken also. The fix is identical - wrap apr_time_from_sec around the result of apreq_atoi64t. > While testing this I figured another problem, the secure flag > is not working either ! Oops! > But the path and the domain attributes are ! > So maybe you'll find some time to fix this as well :-) > > Anyway, thanks for your help and the solution. > > BTW, when will the fix be part of the cvs ? The fixes are ready; what's missing are the corresponding tests to ensure the bugs don't reappear. nb- folks can always add more tests to demonstrate bugs without necessarily having a corresponding fix. A patch to the test suite which demonstrates a bug is absolutely the best kind of bug report. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Mod Perl + Apache Error logs, extend DBILogger
<[EMAIL PROTECTED]> writes: > This information is most helpful in understanding what is going on. > That would be the logical thing to think that the during the perlhandler > phase the content() gets sucked up and isn't available for [...] > This is what I have below, the problem I'm trying to solve is getting > the params (text field etc.) that were passed to a cgi script. This > Apache module is being called in my httpd.conf by "PerlLogHandler > Apache::ErrorLogger". Unfortunately there's no good solution for your problem in mp1-land, because the POST data winds up wherever the content handler (or some earlier handler) puts it. Unless that's using Apache::Request as well, I'm afraid there's no way to get at the POST data with libapreq. However, because of the input filtering design built into apache2, you _can_ do what you want with mp2/apreq2, no matter what the content handler is (it doesn't even need to be perl-related). All you'd need to do is make sure mod_apreq's filter gets inserted before the content-handler takes over, and then Apache::Request will provide full access to the parsed POST data. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File uploads using Apache:;request in mod_perl2
"Pete Smith" <[EMAIL PROTECTED]> writes:
[...]
> my $image_upload = $r->upload('image');
> my $file_handle = $image_upload->fh();
>
> read ($file_handle, my $full_image_data, (stat($file_handle))[7]);
>
> my $imager = Imager->new();
>
> $imager->open(data => $full_image_data, type => 'jpeg');
> my ($width) = imgsize(\$full_image_data);
>
>
> I now know that I could pass the file handle to Imager and Image::Size
> instead of turning into a scalar stream, but that isn't the problem.
>
> I have discovered that Apache::Request for mod_perl2 has changed the
> fh method to bb, which apparently returns an APR::Brigade (object I
> presume) instead of a file handle.
>
> I have looked for documentation for APR::Brigade, but can find none. I
> have no idea what it is!
APR::Brigade is, well, the perl glue for libaprutil's apr_brigade_t C struct.
Along with buckets, they are used throughout the filter api, both in
apache2 and mp2 (collectively referred to as "bucket brigades").
> Could somebody please point me in the right direction as to how I can
> achieve the above in mod_perl2?
In your mp1 code, you are simply slurping the upload into
$full_image_data; with apreq2 you can do that with a bucket
brigade via
my $bb = $req->upload('image')->bb;
my $full_image_data = "";
while (my $b = $bb->first) {
$b->read(my $buffer);
$full_image_data .= $buffer;
$b->remove;
}
I'm sure there are better ways to use the brigade API
though. The C API for brigades has a "flatten" function-
does anyone know if mp2 has glue for that yet?
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: libapreq2 and FreeBSD
Martin Nilsson <[EMAIL PROTECTED]> writes: > I'm trying to install libapreq2-2.02-dev on FreeBSD 4.9 with Perl > 5.6.1 and Apache 2.048 mod_perl2-1.99r12 all installed from ports. Wonderful! Thanks alot! [...] > Files: > ///usr/local/lib/perl5/5.6.1/man/man3/Apache::Cookie.3 > ///usr/local/lib/perl5/5.6.1/man/man3/Apache::Request.3 [...] > ///usr/local/lib/perl5/site_perl/5.6.1/mach/auto/libapreq2/.packlist > > Thanks for any help making this work! The perl glue looks ok to me. Where did mod_apreq.so and libapreq2.so wind up going? mod_apreq should be in apache2's module directory, and libapreq2 should be alongside libaprutil. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File uploads using Apache:;request in mod_perl2
Geoffrey Young <[EMAIL PROTECTED]> writes:
[...]
> I'm not as familiar with brigades as I should be, but does
> it save you the iteration process or is it just a substitute for
> reading to a buffer?
It'd save you the iteration process (it's an APR::Brigade method,
not APR::Bucket), but would not destroy the buckets within the
brigade (hmm, does APR::Brigade have a DESTROY method?).
The advantage here is you'd be able to accomplish this
in one or two lines of perl, ie.
my $upload_data = $req->upload('file')->bb->flatten;
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File uploads using Apache:;request in mod_perl2
Geoffrey Young <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> > my $upload_data = $req->upload('file')->bb->flatten;
>
> oooh, nice. I can definitely see that being a useful idiom.
Not sure if it'd be better for flatten to take $upload_data as
an argument and return a status code instead, but I'll happily
leave that decision for the implementer :-).
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File uploads using Apache:;request in mod_perl2
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> It doesn't sound like a good idea. Users ain't need to mess with
> bucket brigades, unless they really want to. If the upload is always
> going through the temp file, why making things complex for the users?
Exactly because it is NOT always going through a temp file.
Just look further upthread- this particular user doesn't
even *want* a temp file, just the data. Why should he need
to make all those "open/read/write/close file" system calls
if he doesn't need them?
> In any case it's the best to hide the internals behind an API,
> so you can do:
>
> my $upload_data = $req->upload('file')->slurp;
>
> and inside slurp you have the C API to do anything you need. How
> does that sound?
That's a possibility, but I fail to see its advantage over
APR::Brigade exposing flatten(). It is part of the C API
after all, eh? Why shouldn't perl programmers have access
to it?
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: File uploads using Apache:;request in mod_perl2
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > You need the filehandle only if you use the temp file. In which case > bbs are irrelevant. If you use slurp then there is are no > filehandles. I think these are orthogonal. Agreed- my earlier +1 was for both adding a slurp() method and marking the output as tainted. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache Request and libapreq2 Cookie woes
"Beau E. Cox" <[EMAIL PROTECTED]> writes:
[...]
> ($self->{cookie_class} is 'Apache::Cookie')
> my $cookie =
> $self->{cookie_class}->new( Apache->request, ... );
> -- OK
This is correct usage, because Apache->request is an
Apache::RequestRec object in mp2.
>
> my $cookie =
> $self->{cookie_class}->new( $self->apache_req, ... );
> -- Segmentation fault (11)
>
> my $apr = Apache::Request->new( $self->apache_req );
> -- Segmentation fault (11)
These are (currently) incorrect calls, because the argument
to new() MUST be an Apache::RequestRec object, not an
Apache::Request object. The segfault is of course a bug
in Apache::Request, but in the meantime you can avoid it by
using env() to pull the base Apache::RequestRec object out of
your Apache::Request object:
my $cookie = $self->{cookie_class}->new($self->apache_req->env,...);
my $apr = $self->apache_req; # (no need to call new() here)
--
Joe Schaefer
--
Reporting bugs: 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: [mp2] $r->status does not accept a valid parameter
<[EMAIL PROTECTED]> writes: [...] > $r->status(Apache::HTTP_MULTI_STATUS); > or > $r->status(207); > > always results in the following > > Usage: Apache::Request::status(sv) at API/Modes.pm > line 235. $r->status is read-only for Apache::Request objects; you either want $r->env->status(207); # env() yields Apache::RequestRec obj or $r->SUPER::status(207); # Apache::RequestRec is the base # class for Apache::Request (in mp2) Not sure if this solves your overall problem, but it should resolve this part of it. -- Joe Schaefer -- Reporting bugs: 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: [mp2] Am I leaking memory?
"Beau E. Cox" <[EMAIL PROTECTED]> writes: [...] > The only place in my Mason changes I can see anything funny is: > > # This gets the proper request object all in one fell swoop. We > # don't want to copy it because if we do something like assign an > # Apache::Request object to a variable currently containing a > # plain Apache object, we leak memory. This means we'd have to > # use multiple variables to avoid this, which is annoying. > my $r = > $r_sub->( $self->args_method eq 'mod_perl' ? > Apache::Request->new( $_[0] ) : > $_[0] > ); > > I changed: > Apache::Request->instance( $_[0] ) : > to: > Apache::Request->new( $_[0] ) : > > Is that causing trouble? No, your change is fine. AFAICT that comment pertains to an esoteric problem with object cleanup in libapreq/mp1, but the bug doesn't seem to be carried over into mp2/apreq2 (the apreq2 test suite has a test for it). -- Joe Schaefer -- Reporting bugs: 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: File uploads using Apache:;request in mod_perl2
Kevin Bosak <[EMAIL PROTECTED]> writes:
> I too am having issues with file uploads using mod_perl2. I've gotten
> the beta of Apache::Request but it looks like from this thread that
> there's not yet a way to retrieve the uploaded file. Is this true?
No, it's not true at all. If you don't need to read the contents of the
upload, but just need to store it in a file somewhere, use
$upload->link("/path/to/local/file"). If you do need to read the
contents, use the APR::Brigade API on $upload->bb. A future version
of Apache::Request may have include convenience methods (like slurp(),
etc.), but you can certainly get at the uploaded file using the current
version.
The brigade API is a big performance-win for libapreq2, since it allows
us to use a zero-copy design on file uploads until the file gets too
big to store in memory. The size limit is currently 256K, but the size
will be configurable in future versions.
--
Joe Schaefer
--
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: File uploads using Apache:;request in mod_perl2
Kevin Bosak <[EMAIL PROTECTED]> writes:
> I can get the file's name but the upload
> is simply not getting linked/saved. I'm sure it's probably something
> I'm doing wrong, but I don't know what. Here's the relevant lines
> from my code:
>
>my $upload = $r->upload('file');
>my $filename = $upload->filename;
>$upload->link("/path/to/local/$filename");
>
> Is there something I can do to troubleshoot this?
Three things to check:
1) be sure $filename is valid (it really should be marked as tainted),
2) be sure "/path/to/local/$filename" is on the same device
(filesystem) as your temporary directory (see the docs for
Apache::Request::new regarding TEMP_DIR).
3) check the return value of $upload->link, if it's false (undef) then
there was a problem- usually the trouble is caused by one of the above.
--
Joe Schaefer
--
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: File uploads using Apache:;request in mod_perl2
Kevin Bosak <[EMAIL PROTECTED]> writes: > Thanks for the advice. > I checked and $upload->link does indeed return false. I'm guessing > it's because of something with TEMP_DIR you said, but my lack of > knowledge is keeping me from getting this resolved. How do I > determine what TEMP_DIR has been set to? At the moment, grepping Mason's source files for TEMP_DIR or TMPDIR is probably the only solution. I don't think the current Apache::Request for mp2 exposes enough of the C API to be of any help to you. > I'm using Mason with ApacheHandler2 that I believe sets up the > Apache::Request object but I'm still a little unclear on how > everything fits together. I could definitely use another "nudge" in > the right direction. If you're using glibc, the sledgehammer approach is to have the sysadmin set/export the TMPDIR environment variable prior to server startup, ie. % TMPDIR=/path/to/my/tmpdir apachectl restart This will override any TEMP_DIR settings coming from calls to Apache::Request::new(). btw- I'm planning to $upload->link so that it will handle the cross-device situation more gracefully (by making a full copy of the tempfile should the internal PerlLIO_link fail). -- Joe Schaefer -- 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: File uploads using Apache:;request in mod_perl2
Kevin Bosak <[EMAIL PROTECTED]> writes:
> Thanks again for the help but still no luck.
> I set the TMPDIR environment variable manually and restarted apache
> but still can't get the upload file in my script and nothing's being
> written to the tmpdir. If there's anything else I can try please let
> me know but I may just end up having to use CGI.pm for uploads.
Try replacing the apreq_xs_upload_link() function in
glue/perl/xsbuilder/Apache/Request/Apache__Request.h
with the following one; rebuild and install it. If this
doesn't solve your problem, the next release should include more
helpful diagnostics, but until then CGI.pm is always available.
APR_INLINE
static XS(apreq_xs_upload_link)
{
dXSARGS;
MAGIC *mg;
void *env;
const char *name, *fname;
apr_bucket_brigade *bb;
apr_file_t *f;
if (items != 2 || !SvROK(ST(0)))
Perl_croak(aTHX_ "Usage: $upload->link($name)");
if (!(mg = mg_find(SvRV(ST(0)), PERL_MAGIC_ext)))
Perl_croak(aTHX_ "$upload->link($name): can't find env");
env = mg->mg_ptr;
bb = apreq_xs_rv2param(ST(0))->bb;
name = SvPV_nolen(ST(1));
f = apreq_brigade_spoolfile(bb);
if (f == NULL) {
apr_off_t len;
apr_status_t s;
const apr_int32_t flags = APR_CREATE | APR_EXCL | APR_WRITE |
APR_READ | APR_BINARY | APR_BUFFERED;
s = apr_file_open(&f, name, flags,
APR_OS_DEFAULT,
apreq_env_pool(env));
if (s != APR_SUCCESS ||
apreq_brigade_fwrite(f, &len, bb) != APR_SUCCESS)
XSRETURN_UNDEF;
XSRETURN_YES;
}
if (apr_file_name_get(&fname, f) != APR_SUCCESS)
XSRETURN_UNDEF;
if (PerlLIO_link(fname, name) >= 0)
XSRETURN_YES;
else {
apr_status_t s = apr_file_copy(fname, name,
APR_OS_DEFAULT,
apreq_env_pool(env));
if (s == APR_SUCCESS)
XSRETURN_YES;
}
XSRETURN_UNDEF;
}
--
Joe Schaefer
--
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: Apache::Cookie and CGI::Cookie Interoperability
Stas Bekman <[EMAIL PROTECTED]> writes:
> James Taylor wrote:
> > I'm having difficulty getting my mod_perl scripts and then my
> > non-mod_perl scripts reading cookies between each other. I have a
> > mod_perl TransHandler that sets a cookie via Apache::Cookie, and
> > then I have some scripts in my /cgi-bin that try and read the cookie
> > using basic CGI::Cookie. It doesn't appear to be working
> > whatsoever, as the Apache::Cookie script can't read any of the
> > cookies set by CGI::Cookie and vice-versa. I tried ditching
> > Apache::Cookie in the transhandler and using CGI::Cookie as well,
> > but still the two can't see each other.
> > Any ideas what would cause something like this?
>
>
> You can't do it this way. Since when you try to retrieve the cookie
> from your cgi, it reads the cookies from $ENV{HTTP_COOKIE} ||
> $ENV{COOKIE}, whereas your TransHandler doesn't set those env-vars
> (one of the two), and that's what it should do. Moreover, most likely
> it should use $r->subprocess_env to do that, and not setting %ENV.
Amplififying on Stas's reply, there's a big difference between incoming
(request) cookies and outgoing (response) cookies. When you set
(or bake) a cookie, it's _outgoing_, so you're ultimately creating
something that will only appear in the *response* headers. On the
other hand, when these modules parse cookies, they're only looking
at the *request* headers, since that's where the *incoming* cookies
appear.
IOW, you shouldn't try to set/bake cookies as a means of passing
data from one handler to another one *inside the same request*.
Cookies are a means of passing data between two different requests,
and the module APIs reflect that.
--
Joe Schaefer
--
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: [mp2] Using MP2 to rewrite URLs based on POST Body data
"Greg Balmer" <[EMAIL PROTECTED]> writes: [...] > Basically our service has a single access point > http://ourhost.com/Service and I want to be able to examine the POSTed > (XML) content of requests for keywords in the body and rewrite the > incomming url as follows - > > Request BODY : "..keyword1.." then rewrite the URL > to http://ourhost.com/Service-method1 > Request BODY : "..keyword2.." then rewrite the URL > to http://ourhost.com/Service-method2 > ... If there was an xml parser available for libapreq2, you could use Apache::Request to do this without any worries. [...] > I'm a bit of a newbie to this stuff, but I think this may be > achievable with InputFilters, so I was really looking for any pointers > that anyone could give. It is, but you need to be very careful about spooling the post data for the redirected url. This is basically what mod_apreq.c does in libapreq2, but it's pretty tricky. Perhaps convincing apreq-dev@ to support xml would be your best bet. -- Joe Schaefer -- 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: Problem with modperl2/apache2/apreq2 upload
"Ken Burcham" <[EMAIL PROTECTED]> writes:
> I've been reading and trying things all day to no avail which
> usually means I'm doing something stupid. I have a perl apache
> module running under Apache 2.0.48/Mod_perl
> 1.99_13/libapreq2.02_02 and I'm trying to take a file upload.
>
> I'm getting a segfault whenever I call $req->upload with a
> parameter:
>
> my $upload = $req->upload('somefilename');
That's certainly supposed to work, assuming 'somefilename' is
the name of the upload widget in your HTML form. Can you post
a backtrace for the segfault?
> I can, however, call: my @uploads = $req->upload; and it returns
> to me an array of parm names. In apache1, a call to ->upload
> would return to me just upload objects whereas in apache2 it is
> apparently returning every param name on the form. Is that
> right?
That is correct. In apache1 the uploads formed a linked list
internally, but that's no longer true in apreq2. In apreq2
$req->upload follows the same interface pattern as $req->param.
--
Joe Schaefer
--
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: Problem with modperl2/apache2/apreq2 upload
"Ken Burcham" <[EMAIL PROTECTED]> writes:
> > That's certainly supposed to work, assuming 'somefilename' is
> > the name of the upload widget in your HTML form. Can you post
> > a backtrace for the segfault?
>
> Sure... umm... how do I do that? :)
>
> I'm still pretty new to perl.
Segfaults arise from buggy C code. For instructions on generating
a backtrace, read
http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults
> >
> > That is correct. In apache1 the uploads formed a linked list
> > internally, but that's no longer true in apreq2. In apreq2
> > $req->upload follows the same interface pattern as $req->param.
>
> How do I get to just the upload items? Or do I test via $upload-
> >info/type?
No need to test anything: $req->upload() works just like
$req->param(), but it is restricted to uploads only. For example
my $upload_table_ref = $req->upload; # APR::Table ref of uploads
foreach my $name (keys %$upload_table_ref) {
my @uploads = $req->upload($name); # Array of Apache::Upload
# objects having name = $name
# do something with @uploads
}
--
Joe Schaefer
--
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: Problem with modperl2/apache2/apreq2 upload
"Ken Burcham" <[EMAIL PROTECTED]> writes: > Ok, I might be on to something... > > I think the segfault is coming when I call 'upload' with a non- > upload field... But since calling 'upload' without a name > returns to me a list of variable names that include non-upload > fields, iterating through guarantees me to segfault: > > (NOTE: resourceurl is the only 'file' field on my form with 23 > other 'text' fields) > > my $q = Apache::Request->new($r); > > my @uploads = $q->upload; OK, I see the problem now. In list context $q->upload() is failing to filter out the non-upload keys. It should get fixed in the next release, but in the meantime try using $q->upload() in scalar context. That will give you an Apache::Upload::Table (@ISA=APR::Table) to work with. The table will only contain uploads, and since it's a tied hash, you can iterate over it using keys() or each(). -- Joe Schaefer -- 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: Problem with modperl2/apache2/apreq2 upload
"Ken Burcham" <[EMAIL PROTECTED]> writes:
[...]
> foreach my $key (keys %{$uploads})
> {
>warn "Uploader found $key";
>
>my $upload = $uploads->{$key};
>
>warn "Found $upload->filename";
>
> }
[...]
> But nothing else as if my foreach finds nothing... What am I
> missing? :)
No clue at the moment- foreach(keys %$uploads) should loop once
for the upload file. I'll look into that problem also.
[...]
> warn "There was a problem uploading: $uploadfile" unless $upload-
> >link($uploadfile);
>
> Am I on the right track with this? It fails... In another
> thread (http://www.gossamer-
> threads.com/archive/mod_perl_C1/modperl_F7/File_uploads_using_Apa
> che:%3Brequest_in_mod_perl2_P101676), you mention 3 possibilities
> as to why it could fail and it implicates a temp directory...
Yes, your problem with link() is likely the temp dir location.
That problem is resolved in current cvs, and with the patch I
posted on that thread.
>
> I'm expecting it to write to that file. The $upload_dir exists,
> but the file obviously doesn't because I'm trying to upload it...
>
> Do I need to ->bb and then write it?
No, link() will do it for you; use current cvs or apply the patch.
--
Joe Schaefer
--
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: Missing submit button if after a file field
"Rob Mueller" <[EMAIL PROTECTED]> writes: > I submitted this to the lib-apreq mailing list ([EMAIL PROTECTED]) > but didn't hear anything back, so I thought I'd try here... Odd that you say there was no answer, when the ensuing apreq-dev@ discussion (http://marc.theaimsgroup.com/?t=10814601034&r=1&w=2) 1) researched the issue and determined the cause, tracing it back to a similar report on February 6, 2002 (from you!) regarding Mozilla 0.97: http://marc.theaimsgroup.com/?l=apache-modperl&m=101295988431701&q=raw 2) determined that the missing CRLF from Konqueror is still RFC-compliant: http://marc.theaimsgroup.com/?l=apreq-dev&m=108184431529065&w=2 3) resulted in a patch to httpd-apreq-2 cvs over the weekend: http://marc.theaimsgroup.com/?l=apreq-cvs&m=108225244312182&w=2 There is no patch available for httpd-apreq (libapreq-1), because nobody (myself included) has volunteered one yet. It may wind up simply being documented as a bug if nobody fixes it before the next release of httpd-apreq. I'll answer your email directly below, in the hopes of clearing this up for you so some motivated person might patch httpd-apreq. [...excellent bug report elided...] > To be honest, I haven't dug through the spec to see if buttons are supposed > to come before other fields, but as far as I can tell, this problem only > happens if the button field is submitted by the browser immediately after a > file field, The empty file field coming from Konqueror is missing a CRLF. That does not violate RFC 2046, however it breaks httpd-apreq's mfd parser (probably CGI.pm's also) because the parser assumes that CRLF will be there. This is the reason why the subsequent "Submit" button is missing from the params: the parser interpreted its block as being the upload file's contents. The missing CRLF causes the parser to skip over the boundary string separating the (empty) file block from the "Submit" button's block. -- Joe Schaefer -- 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: building 64-bit
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> It should be possible to automate this search by getting cvs version bumped up
> incrementally and grepping for that split line, untill the change is
> found. It'd be a nice addition to our toolset.
What's wrong with cvs annotate here?
gemini:~/src/apache/modperl$ cvs annotate Makefile.PL | grep PERL_EXTRA_CFLAGS
Annotations for Makefile.PL
***
1.174(dougm23-Dec-00): $PERL_EXTRA_CFLAGS = "";
1.4 (hartill 10-Feb-98): $PERL_EXTRA_CFLAGS .= " -D${k}=1";
1.86 (dougm28-Aug-98): $PERL_EXTRA_CFLAGS .= " -D$_=1";
1.81 (dougm30-Jul-98): $PERL_EXTRA_CFLAGS .= " -DPERL_SAFE_STARTUP=1";
1.201(dougm23-May-02): $PERL_EXTRA_CFLAGS .= " $Config{ccflags}";
1.201(dougm23-May-02): $PERL_EXTRA_CFLAGS =~ s/-D_GNU_SOURCE//;
1.144(dougm07-Mar-00): if($PERL_EXTRA_CFLAGS) {
1.144(dougm07-Mar-00): $PERL_EXTRA_CFLAGS = join(" ", split(",",
$PERL_EXTRA_CFLAGS));
1.144(dougm07-Mar-00): $PERL_EXTRA_CFLAGS =~ s/\s+/ /g;
1.144(dougm07-Mar-00): $PERL_EXTRA_CFLAGS .= " -g";
1.144(dougm07-Mar-00): $PERL_EXTRA_CFLAGS .= "
-DPERL_DESTRUCT_LEVEL=$PERL_DESTRUCT_LEVEL"
1.55 (dougm25-Jun-98): if($PERL_EXTRA_CFLAGS) {
1.55 (dougm25-Jun-98): $cmd .= qq(CFLAGS="$PERL_EXTRA_CFLAGS" );
1.4 (hartill 10-Feb-98): $inc .= " $PERL_EXTRA_CFLAGS" if
$PERL_EXTRA_CFLAGS;
gemini:~/src/apache/modperl$ cvs log -r1.144 Makefile.PL
RCS file: /home/cvspublic/modperl/Makefile.PL,v
Working file: Makefile.PL
head: 1.219
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 219; selected revisions: 1
description:
revision 1.144
date: 2000/03/07 03:12:36; author: dougm; state: Exp; lines: +26 -25
fix Makefile.PL if $USE_APXS && $PERL_DEBUG
=
Doesn't look like the cvs log is going to be of much help;
perhaps checking the list archives in Feb/March 2000 will
turn up something useful.
--
Joe Schaefer
--
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
libapreq2-2.03-dev-rc3 available for testing
Folks,
Please take this release candidate out for a test drive
http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz
and report back your success/failure. I'd like to get
this new developer release of libapreq2 on CPAN this weekend,
but I need a few volunteers to test it and report back
on their experience (please include platform and version
numbers for perl, mp2, and apache2 in your response).
== Changes with libapreq2-2.03-dev ==
- C API [joes]
"Objectify" cookie/jar API: s/apreq_(make|serialize)_cookie/apreq_cookie_$1/
and reordering args so the cookie/jar object is always the first argument.
Macros added to provide source-compatibility with the old names.
- Perl API [joes]
Added $upload->slurp($data), which reads the contents of the file
upload "$upload" into the scalar "$data".
- C API [joes, randyk]
apreq_run_(hook|parser) are macros, so they are capitalized now.
Fixed apreq_params_as_string() and added apreq_params_as_array().
Reworked definitions of APREQ_DECLARE_HOOK, APREQ_DECLARE_PARSER
and apreq_(parser|hook)_t, hopefully to be more Win32 friendly.
Also updated the documentation.
- C API [joes]
Compensate for a missing CRLF in empty file upload block, which
actually complies with RFC 2046 Section 5.1.1. Konqueror (version unknown)
and Mozilla 0.9.7 are known to emit such blocks.
- Perl API [joes]
$req->upload() in list context failed to filter out non-uploads.
Also $req->upload("nonexistent-key-name") segfaults.
- Perl test suite
t/TEST.PL must run parent class' pre_configure to get the
configuration right
- C API [joes]
apreq_brigade_concat() wasn't supplying the final EOS bucket
to large brigades (>256K), which somtimes caused the prefetch
loop in mod_apreq.c's apreq_filter() to hang.
- Documentation [joes]
CHANGES file reformatted, removing dates & other clutter
as Stas suggests.
- C API [joes]
Rewrote cgi_read() in apreq_env.c and reworked mod_apreq.c
to enforce apreq_env_max_body() settings.
- C API [joes]
Fixed bug in url_parser code- missing context brigade was
needed to track key-value pairs which span multiple buckets.
- C API [joes]
API modifications: removed struct apreq_cfg_t, adding
new apreq_env hooks max_body, max_brigade_len, and temp_dir.
Folded apreq_parsers.h into apreq_params.h and modified the arguments
to apreq_run_parser() and apreq_run_hook(). Renamed
apreq_parser_t's content_type as enctype and apreq_copy_brigade()
as apreq_brigade_copy().
These changes make libapreq2.so.2.0.5 incompatible with earlier
versions.
- Perl API [stas]
Include ppport.h from blead-perl to support older perls.
Add a proper support for ithreads.
- C API [Swen Schillig, joes]
Fixed bug in calculation of Netscape cookie expiration dates.
apr_time_t is measured in microseconds, not seconds, which
threw off the arithmetic; apr_time_from_sec was needed for
the conversion.
- C API [Max Kellermann]
Fix segfault caused by invalid %-escape sequence in query string.
==
Thanks!
--
Joe Schaefer
--
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
[ANNOUNCE] libapreq2-2.03-dev released
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 2.03 developer release of libapreq2.
The libapreq2-2.03_04-dev.tar.gz package has been released under
the new Apache License version 2.0. The package is now available
through the ASF mirrors
http://www.apache.org/dyn/closer.cgi/httpd/libapreq2-2.03_04-dev.tar.gz
http://www.apache.org/dyn/closer.cgi/httpd/libapreq2-2.03_04-dev.tar.gz.asc
and has entered CPAN as
file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.03_04-dev.tar.gz
size: 447648 bytes
md5: 18cefa860f15812ed35c5e1eb52f9a0a
==
Changes with libapreq2-2.03-dev
- C API [joes]
"Objectify" cookie/jar API: s/apreq_(make|serialize)_cookie/apreq_cookie_$1/
and reordering args so the cookie/jar object is always the first argument.
Macros added to provide source-compatibility with the old names.
- Perl API [joes]
Added $upload->slurp($data), which reads the contents of the file
upload "$upload" into the scalar "$data".
- C API [joes, randyk]
apreq_run_(hook|parser) are macros, so they are capitalized now.
Fixed apreq_params_as_string() and added apreq_params_as_array().
Reworked definitions of APREQ_DECLARE_HOOK, APREQ_DECLARE_PARSER
and apreq_(parser|hook)_t, hopefully to be more Win32 friendly.
Also updated the documentation.
- C API [joes]
Compensate for a missing CRLF in empty file upload block, which
actually complies with RFC 2046 Section 5.1.1. Konqueror (version unknown)
and Mozilla 0.9.7 are known to emit such blocks.
- Perl API [joes]
$req->upload() in list context failed to filter out non-uploads.
Also $req->upload("nonexistent-key-name") segfaults.
- Perl test suite
t/TEST.PL must run parent class' pre_configure to get the
configuration right
- C API [joes]
apreq_brigade_concat() wasn't supplying the final EOS bucket
to large brigades (>256K), which somtimes caused the prefetch
loop in mod_apreq.c's apreq_filter() to hang.
- Documentation [joes]
CHANGES file reformatted, removing dates & other clutter
as Stas suggests.
- C API [joes]
Rewrote cgi_read() in apreq_env.c and reworked mod_apreq.c
to enforce apreq_env_max_body() settings.
- C API [joes]
Fixed bug in url_parser code- missing context brigade was
needed to track key-value pairs which span multiple buckets.
- C API [joes]
API modifications: removed struct apreq_cfg_t, adding
new apreq_env hooks max_body, max_brigade_len, and temp_dir.
Folded apreq_parsers.h into apreq_params.h and modified the arguments
to apreq_run_parser() and apreq_run_hook(). Renamed
apreq_parser_t's content_type as enctype and apreq_copy_brigade()
as apreq_brigade_copy().
These changes make libapreq2.so.2.0.5 incompatible with earlier
versions.
- Perl API [stas]
Include ppport.h from blead-perl to support older perls.
Add a proper support for ithreads.
- C API [Swen Schillig, joes]
Fixed bug in calculation of Netscape cookie expiration dates.
apr_time_t is measured in microseconds, not seconds, which
threw off the arithmetic; apr_time_from_sec was needed for
the conversion.
- C API [Max Kellermann]
Fix segfault caused by invalid %-escape sequence in query string.
==
--
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: Apache::Request
"David Hofmann" <[EMAIL PROTECTED]> writes: > I see that there a development version. Is there a stable version that > works for Mod Perl 2.0 or something the can be easily put in it's place? No, there isn't. My guess is that there will only be one more developer release in a few months, which will include the recent SSL bugfixes and full support for Apache::Request in CGI mode (libapreq2 already works with CGI; mp2 is being reshuffled a bit to allow Apache::Request to work there as well). I'd really like to see a stable release happen before November's Apachecon, and I don't expect Apache::Request to change much between now and then. Even so, now is a very good time to try it out, because you actually may want some things changed before we "stabilize" it :-). There are plenty of open issues in the httpd-apreq-2 STATUS file that would benefit from user-feedback. -- Joe Schaefer -- 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: Apache::Request
Stas Bekman <[EMAIL PROTECTED]> writes: > Kreimendahl, Chad J wrote: > > http://httpd.apache.org/apreq/ > > Install using one of the following methods: > > (easiest way) > > perl Makefile.PL --with-apache2-apxs=/path/to/apache2/bin/apxs > > (or, same thing, different method) > > ./configure --with-apache2-apxs=/path/to/apache2/bin/apxs > > --enable-perl-glue --with-perl=/path/to/perl/binary > > (then, the standard) > > make > > make test > > make install > > This appears to install over top of the existing module, unlike > > installing in an Apache2 directory (like those of us who had mp1 and mp2 > > running). So there may be problems in mp1 once this is done... I'd test > > it, but my mp1 is long gone. > > That's strange. I get it installed under Apache2/ subdir (assuming > that you had mp2 installed into Apache2/ subdir). You may want to > report all the details to the apreq-dev mailing list. +1. The 1.X and 2.X versions of Apache::Request should happily coexist if mp2 was configured with MP_INST_APACHE2=1. Only the installed Unix manpages will overlap; anything else is a bug and should be reported to [EMAIL PROTECTED] -- Joe Schaefer -- 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: [mp2] losing POST vars with PerlOutputFilterHandler+mod_proxy
"Eric J. Hansen" <[EMAIL PROTECTED]> writes:
> I'm having a problem whereby I can't access POST CGI variables when using
> an output filter (PerlOutputFilterHandler) alongside mod_proxy.
> Parameters on the URL (GET) work just fine, its just the POST variables
> that are missing.
>
> My setup is that I'm using a mod_proxy reverse proxy to fetch some remote
> content, then doing some analysis on the content using an output filter.
The problem is likely that the apreq filter has not been added to
the input filter chain in time to read the POST data.
There are two solutions to this problem:
1) Write a filter init handler for you filter that instantiates an
Apache::Request object. See
http://perl.apache.org/docs/2.0/api/Apache/Filter.html#C_FilterInitHandler_
2) Use .htaccess or your server config to ensure the apreq input filter
is active for this request with "AddInputFilter APREQ" or somesuch.
I recommend using (1), and falling back to (2) until you get (1) working.
> I suspect this has something to do with mod_proxy consuming the
> request data - i.e., once the data of the HTTP request is read, its gone
Correct.
[...]
> sub handler { # (filter)
> my $f = shift;
> my $r = $f->r;
>
> if ( ! $r->notes('not_first_bucket') ) {
> $r->notes->set('not_first_bucket' => 1);
>
> my $ApReq = Apache::Request->new($r);
> my $CgiArgsRef = $ApReq->param;
>
> # log CGI variables for debug...
> $CgiArgsRef->do( sub {
> $r->log_error("CGI parameter: '" . $_[0] .
>"' = '" . $_[1] . "'");
> return 1;
> });
> )
>
> return Apache::DECLINED;
> }
>
> And if I install this as an INPUT filter,
^
Danger, Will Robinson! Generally speaking, you should *not* use
Apache::Request::param inside an input filter. Otherwise you run
the very real risk of an infinite recursion error. The apreq
filter will always insert itself as the very *last* input filter in
the chain, which means it'll call *your* input filter in order to
get at the requested POST data. It looks like you managed to carefully
avoid the infinite recursion in your example, but I'm not sure the
underlying Apache::DECLINED perl magic is smart enough to handle the
reentry- thus the 502.
--
Joe Schaefer
--
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: [mp2] losing POST vars with PerlOutputFilterHandler+mod_proxy
Geoffrey Young <[EMAIL PROTECTED]> writes:
> Eric J. Hansen wrote:
> > Thanks, Joe! I implemented your suggestion (1), and the following
> > works nicely... (added to my request filter)
> >
> > sub init : FilterInitHandler {
> > my $f = shift;
> > my $r = $f->r;
>
> wow, a FilterInitHandler in the wild. guess it was a good idea to
> support that after all ;)
IIRC apreq-as-filter was part of the motivation for httpd to even
implement the filter init hook, so yeah, that *was* a good idea :-).
--
Joe Schaefer
--
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: Apache::Request
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > Temporarily we could link to cvs.apache.org, e.g.: > http://cvs.apache.org/viewcvs.cgi/*checkout*/httpd-apreq-2/glue/perl/xsbuilder/Apache/Cookie/Cookie_pod Probably you want the html version, in which case it's best to just link http://cvs.apache.org/~joes/libapreq2-2.04-dev/docs/html/modules.html A more permanent link on the apreq website will be available before the next release. -- Joe Schaefer -- 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: Apache::Request
Kemin Zhou <[EMAIL PROTECTED]> writes: [...] > perl ../../build/xsbuilder.pl run > > This told me to install another package What was the name of the package? ExtUtils::XSBuilder? > Install the required package then run this again. It will generate > the needed file. > > running perl Makefile.PL will not detect this dependency. It's supposed to, so let's try to fix that. -- Joe Schaefer -- 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: Apache::Request
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > There is little value and a huge overhead in building the table files > by each user (not talking about extra dependencies). I know our build/xsbuilder.pl has Win32-specific code in it, so I'm somewhat reluctant to simply generate and bundle the pre-built tables. > It might be a good idea for apreq2 to store the output of recdescent > under cvs and hand it ready to the users. That's similar to what mp2 > does (though it uses C::Scan to do the C parsing). Not opposed in principle, I just don't want to be personally involved in maintaining those tables. -- Joe Schaefer -- 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: [mp2] APR::Table / Apache::Request usage question
Nicholas Studt <[EMAIL PROTECTED]> writes: [...] > When I read this value from a POST or a GET everything works happily. > When I try to add something to the table the add happens without > event, but I can not read the set value back. Actually a segfault is likely here, because Apache::Request::Table does not provide a (safe) overload for APR::Table::add(). You cannot currently assign params to any of the APR::Table-derived objects in apreq2, but this isue should be addressed before the next release. > Am I missing something in how APR::Table works or is there a better > construct I should be using? I haven't tested this, but it should be safe to forcibly re-bless Cparam> into an APR::Table object and do what you want (without breaking anything). Do not try this with $req->args or $req->body though. -- Joe Schaefer -- 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: Uploading files
Kemin Zhou <[EMAIL PROTECTED]> writes: > To the Developers, > > I saw this in the documentation for Apache::Request > > for file upload > >tempname [XXX- Does this mesh with brigade API?] > > Provides the name of the spool file. This method is reserved for > debugging purposes, and is possibly subject to change in a future > version of Apache::Request. > > From a user's point view, this methods has to be available to the > users and not removed in the future. [...] Despite my past grumblings to the contrary, I've added support for tempname to httpd-apreq-2's current-cvs. I don't know what sort of security implications you are concerned about, but perhaps the best thing to do is simply not use tempname, instead using link() - and then delete the linked file yourself once the external app is done with it. -- Joe Schaefer -- 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: Uploading files
Kemin Zhou <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: [...] > >Despite my past grumblings to the contrary, I've added support for > >tempname to httpd-apreq-2's current-cvs. [...] > Thanks for the help. The tempname is not available in mp2. You misunderstood me. When I read your article, I thought you gave sufficient reasons as to why apreq2 should support tempname, so I wrote an implementation and committed it *right then* to cvs. Prior to your article tempname() was unimplemented in apreq2 (in fact it was *removed* from the documentation not more than a day or two prior to your post). [...] > I don't know how this is implemented. I used to write my own file > upload method. Some of my web applications still use these methods. > It is very simple. That's all fine and dandy, but apreq2 is operating under more stringent requirements. There is a coercive effect when you implement your own data parser: unless everyone else adopts your implementation, somebody inevitably gets left out of the loop. apreq2 imposes no adoption requirements on other modules. For instance you can implement an auth handler with apreq2 that parses the post data, which then decides to accept the request and hand it off to a cgi script. The cgi script will still have the full POST data available for it to use/parse. Or you can write a content handler that uses apreq2 which parses the post data and then does an internal redirect to the proxy handler. The proxied server will still see the original POST data, without any extra code by the content-handler author. [...] > Put more thoughts into uploads could benefit the future. Thanks, we'll try. In the meantime I've rolled another snapshot of current-cvs that you're very welcome to try http://cvs.apache.org/~joes/libapreq2-2.04-dev.tar.gz -- Joe Schaefer -- 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: [MP2 Bug] test case t/apr-ext/uuid.t failuer
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > That's your problem, it fails to find those libs. Please show us the > output of: > > apr-config --link-ld --libs > apu-config --link-ld --libs Stas, mp2 may need apr-config --link-ld --ldflags --libs on some platforms. I've seen this on FreeBSD, for example. -- Joe Schaefer -- 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: missing param from post using apache::request
"Ken Burcham" <[EMAIL PROTECTED]> writes: > Hey guys, > > I submitted a bug report to [EMAIL PROTECTED] and it got returned > without comment... (maybe it was the wrong place?) so I guess i'll > post it here since I know Joe Schaefer monitors this list :). Yup, I'm here. Problems with param parsing aren't mp2 bugs, they're apreq bugs. Reporting them on [EMAIL PROTECTED] is probably best, but discussing this here on [EMAIL PROTECTED] should be fine. > Any ideas what's going on here? Thanks! Not at the moment, but I don't understand this "add the character and post" business. Could you please be more specific about that, and please also remove the GCX modules from the handler you'd like me to test (unless the bug disappears without them). Thanks! -- Joe Schaefer -- 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: missing param from post using apache::request
"Ken Burcham" <[EMAIL PROTECTED]> writes: > Actually, one weird thing is that if I use CGI.pm instead of > Apache::Request the parm is there just fine... Maybe it handles > it differently or something... Sorry, I haven't been able to reproduce the bug (using Mozilla to submit the form) yet. Changing the enctype just changes the parser. Since the mfd parser seems ok with your form-data, the problem likely lies in the urlencoded parser in libapreq2/src/apreq_parsers.c. Still digging though... any chance you could test this against current-cvs for apreq and mp2? -- Joe Schaefer -- 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: missing param from post using apache::request
Joe Schaefer <[EMAIL PROTECTED]> writes: [...] > Still digging though... Bug found in src/apreq_parsers.c:split_urlword. The problem is that apreq_decode can fail if a bucket ends in the middle of an escape sequence, which causes the parser to abort. This will be fixed before 2.04-dev is released (probably sometime over the weekend if you're tracking curent cvs). -- Joe Schaefer -- 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: CGI's Generate Pages With Numbers
"Kent, Mr. John \(Contractor\)" <[EMAIL PROTECTED]> writes: > Any idea what would cause a call to a cgi script to return a > non-displayable page with numbers (below)? [...] > Transfer-Encoding: chunked That would, assuming you're viewing the page with a user-agent which doesn't understand it. -- Joe Schaefer -- 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: libapreq2 upload gotcha
John Williams <[EMAIL PROTECTED]> writes: [...] > Request for libapreq2 developers: Could you please either remove or > document this gotcha? The gotcha here is really a generic issue (ie working with bucket brigades through the APR:: modules) so maybe it is (or needs to be) addressed in the mp2 docs. However I wonder why you want to remove the buckets at all? With $upload->bb you probably shouldn't do that, because you're throwing data away that later modules/filters may yet want to use. Btw this is something that changed from 2.02 to 2.03 (we used to give you a copy of the brigade, so you *had* to remove the buckets yourself). There's also a new io() method coming in the coming 3.04-dev release that gives you a brigade copy like $upload->bb used to do, but it has a TIEHANDLE api superimposed. That way you can use perl's read() or <> operator to consume the buckets in $upload->io(). -- Joe Schaefer -- 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: libapreq2 upload gotcha
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > Interesting. What's the type of the bucket? Is that a file bucket? I believe so. File buckets morph into two buckets when you read from them. The current bucket transforms into a heap bucket, and a new file bucket is inserted behind *it*. However, if you remove the file bucket from the brigade *before* you read from it, the morphed file bucket created during the read winds up in limbo, not in the original brigade. -- Joe Schaefer -- 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: libapreq2 upload gotcha
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> Moving $b->remove to the end makes the code horribly kludgy. It's
> better to change the idiom to step through the buckets instead of
> removing them. Adjusting John's sample code:
>
> my $bb = $r->upload('file')->bb();
> open(OUT,">/tmp/test_file");
> for (my $b = $bb->first; $b; $b = $bb->next($b)) {
> $b->read(my $data);
> print OUT $data;
> }
> close OUT;
>
> Joe, does this idiom work fine with file buckets?
In principle this is fine, but there is a practical issue
to consider: this idiom has the effect of reading the file
bucket back into memory until there are no more file buckets
left in the brigade. If the upload was large enough to
warrant a spool file to begin with, slurping it all back into
memory as chunks is not a good idea.
What I'm going to recommend in the Apache::Upload docs is ask
people to use the TIEHANDLE api for io() instead:
my $io = $req->upload("foo")->io;
print while read $io, $_, 8000; # read() will manage the buckets for you
> We need to write a test for this case, but at the moment we have no
> API to create file buckets. I guess we could test that in an output
> filter and have a response handler call sendfile, which should create
> a bucket of file type.
>
> BTW, John you could also do:
>
>my $bb = $r->upload('file')->bb();
>my $len = $bb->flatten(my $data);
>print OUT $data;
>
> though it's probably less memory-usage effective.
Hah, aren't *you* the guy that asked for $upload->slurp(my $data)?
Now you're recommending $upload->bb->flatten, which does exactly
the same thing (deja vu?).
So, can we go back and get rid of slurp() now? :-)
--
Joe Schaefer
--
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: libapreq2 upload gotcha
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> > [...]
> >
> >>Moving $b->remove to the end makes the code horribly kludgy. It's
> >>better to change the idiom to step through the buckets instead of
> >>removing them. Adjusting John's sample code:
> >>
> >> my $bb = $r->upload('file')->bb();
> >> open(OUT,">/tmp/test_file");
> >> for (my $b = $bb->first; $b; $b = $bb->next($b)) {
> >> $b->read(my $data);
> >> print OUT $data;
> >> }
> >> close OUT;
> >>
[...]
> > What I'm going to recommend in the Apache::Upload docs is ask people
> > to use the TIEHANDLE api for io() instead:
> > my $io = $req->upload("foo")->io;
> > print while read $io, $_, 8000; # read() will manage the buckets for you
>
> Do you mean the difference is in being able to request chunks of
> limited size (8k?). Otherwise the two are equivalent.
No, they are not at all equivalent, because io *deletes* the buckets
as it reads them, which puts them right back into the bucket allocator
for immediate reuse. Witness:
% CONTENT_TYPE="multipart/form-data; boundary=AaB03x"
% PERL5OPT="-Mblib -MApache2 -MApache::Upload -MAPR::Bucket -MAPR::Pool"
% export CONTENT_TYPE PERL5OPT
% ls -sh ~/tmp/mfd_post_data
5.0M /home/joe/tmp/mfd_post_data
% perl -wle '$r = Apache::Request->new(APR::Pool->new); \
$bb = $r->upload("pics")->bb; \
for ($b = $bb->first; $b; $b= $bb->next($b)) {$b->read($_)} \
system "ps u $$" ' < ~/tmp/mfd_post_data
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
joe 32201 0.0 0.4 38424 9952 ?S+ 05:34 0:00 perl -wle $r = Ap
% perl -wle '$r = Apache::Request->new(APR::Pool->new);
my $io = $r->upload("pics")->io;
1 while $io->read($_);
system "ps u $$" ' < ~/tmp/mfd_post_data
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
joe 32203 0.0 0.2 33408 4908 ?S+ 05:36 0:00 perl -wle $r = Ap
That's a difference of 5MB, or exactly one full copy of the upload
file into RAM. This is because the for(...) loop transforms the
sole file bucket into a string of heap buckets that aren't cleaned
up until the pool goes away.
[...]
> In any case, I think $r->upload->slurp(my $data) is a goodness as it doesn't
> require the user to even be aware of the internal representation.
I was just teasing :-). Anyway's we can at least rip out the
XS duplication in Apache::Upload and just write slurp in 2 lines
of perl via bb->flatten.
--
Joe Schaefer
--
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: libapreq2 upload gotcha
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > Looks exactly the same internally as the perl for loop. The only > difference is that it calls apr_bucket_delete when it's done with > it. Which you can do with the for() loop just the same. But you didn't *write* that, so we must be talking past each other. I thought the problem this thread was really about was If I'm trying to read all the data in a bucket brigade, *when* is it ok to remove or delete a bucket from the brigade? The straightforward answer is that you should wait until after you've called $b->read(), because read() has all kinds of side effects. The rest of this dialog seems to have taken us nowhere, so I'll just stop here. -- Joe Schaefer -- 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: Accessing form mutiples
"Dermot Paikkos" <[EMAIL PROTECTED]> writes:
[...]
> foreach my $param ($r->param) {
> print STDERR "\$r->$param = ".scalar($r->param($param))."\n";
> # $hash_ref->{$r->param($param)} = 0;
Have you tried using a slice there?
@{$hash_ref}{$r->param($param)} = (); # values are now undef, not 0
You need the slice syntax to put $r->param($param) in list context.
--
Joe Schaefer
--
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: Raw header and body of HTTP request
Honza Pazdziora <[EMAIL PROTECTED]> writes: > I'm using Apache2, mod_perl2. I use Apache::Request, so that I can get > to ->args and ->body data easily. > > At the same time, I would sometimes need to get the raw body data. If the body data is getting lost when you use Apache::Request in mp2, that's a bug in Apache::Request. [...] > Is there any way to retrieve the raw content (and headers) You could write a input filter that goes in front of HTTP_IN (protocol or connection type), which would see the byte stream in raw form (headers unparsed, data unchunked). -- Joe Schaefer -- 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: Raw header and body of HTTP request
Honza Pazdziora <[EMAIL PROTECTED]> writes: [...] > and it works great. However, I'm probably missing something but how > do you do equivalent of $r->read($buffer, 64_000) multiple times? Be sure you've got use Apache::RequestRecIO; somewhere, and everything should work just fine. If not, please file a bug report. -- Joe Schaefer -- 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: Raw header and body of HTTP request
Joe Schaefer <[EMAIL PROTECTED]> writes: > Be sure you've got > > use Apache::RequestRecIO; ^^^ Sorry, typo- should be Apache::RequestIO. -- Joe Schaefer -- 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: Apache::Request multivalued parameters
"David Hofmann" <[EMAIL PROTECTED]> writes:
> I have a form where several of the in hidden fields are named the same thing
> with diffrent values.
>
> With CGI.pm the I can use %in = $readquery->Vars; to put everything in a
> hash. Then I break the values base on \0.
>
> What the best way to do this with Apache::Request, and how does it handle
> multivalued parameters ?
You have quite a few options here:
1) Work with the Apache::Request::Table
$t = $req->param;
and use each(%$t), keys(%$t) and values(%$t) to iterate over the params
in document order (query_string args come first, then the POST
data in the order it was received). To get all entries for a
given parameter, you can use
@foo_vals = $t->get("foo");
You can also use $t->do(...) to iterate over the table entries with
a callback sub.
2) Think of the $req->param method as a "smart-hash", and use it in
the same way you'd use CGI::param (since that's the method
it is patterened after).
3) Try to stop using the $readquery->Vars API, since $req->param is
able to decode binary data with embedded '\0' values in them.
If you can't bring yourself to that, just write your own converter:
sub Vars {
my $req = shift;
map { $_ => join "\0", $req->param($_) } $req->param;
}
I hope this helps.
--
Joe Schaefer
--
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: Apache::Request multivalued parameters
"David Hofmann" <[EMAIL PROTECTED]> writes:
> I was using this system and exporting the results to %in so that I
> could use $in{VAR} in my program.
>
> Which allows me to do
>
> $temp= "BOB";
> print "$temp = $in{$temp}\n";
>
> To my knowledge, which may be lacking considering I just recently
> started playing with refrences, if I use option 1 or 2 I would have to:
>
> $temp= "BOB";
> $bob = $t->get($temp);
> print "$temp = $bob\n";
>
> Is there where way to put the $t->get inside of a "s?
Use $t as a hash-ref:
print "$temp = $t->{$temp}\n";
That only prints the first $temp param (unless your iterating
over the table with each(), which magically pulls the current
$temp param). But you probably don't want $temp multivalued
here unless you don't mind having
print "$temp = $in{$temp}\n";
embed those \0's in your HTML.
--
Joe Schaefer
--
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: libapreq2 versus everything else
Ken Burcham <[EMAIL PROTECTED]> writes: > I heartily agree... it would have saved me a lot of time coming into > mod_perl2 land... The reason it isn't in mp2 is IMO largely a matter of timing (and a bit of politics). apreq-dev wanted to get the C stuff included in httpd's distro, that way mp2 could provide the wrappers for it. However apreq2 was just getting started when httpd-2.0 was declared stable, so the earliest inclusion point apreq-dev could hope for was the 2.2 line. We're stable enough now to be considering 2.04-dev as the final developer's release (more on that soon), so it's really up to the httpd community to determine whether or not httpd-2.2 users will benefit from it. -- Joe Schaefer -- 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: Missing POST data
David Graves <[EMAIL PROTECTED]> writes: [...] > If I stop using all mod-perl on other scripts, the problem > disappears. > > I know it sounds crazy, but non-modperl scripts sometimes don't get > their POST data if I use modperl for other scripts. Are you using a modperl auth handler anywhere? If an auth handler has been coded to use CGI.pm, it will consume the POST data and your cgi scripts won't ever get it. -- Joe Schaefer -- 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: APR::Poll support -- first cut
Stas Bekman <[EMAIL PROTECTED]> writes: > in order to accept your code, it should be either posted here without any > copyright notices in the post (which automatically makes it a public domain), No, it doesn't: http://www.copyright.gov/fls/fl100.html ... Since the Berne Convention prohibits formal requirements that affect the exercise and enjoyment of the copyright, the United States changed its law on March 1, 1989 to make the use of a copyright notice optional. IMO a patch containing a copyright notice is problematic because it's no longer clear the author intends for it to be treated as a typical contribution to the project. -- Joe Schaefer -- 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: [mp2] a little OT, problem finding libapr
Carl Brewer <[EMAIL PROTECTED]> writes: [...] > Out of curiosity, is anyone working on docs for apreq2 for > people in a hurry? :) Ie: with simple examples in it? Not that I am aware of; I think that makes you the first volunteer :-). May I suggest you add these to FAQ.pod instead of the API docs? There are plenty of examples in those already, and the neat thing is that almost all of them are tested to work as documented. -- Joe Schaefer -- 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: Threaded MPM and performance (was: Re: Variables in memory.)
Larry Leszczynski <[EMAIL PROTECTED]> writes: [...] > The above link mentions the memory benefits of having few perl intepreters > among many threads e.g. if you have a mix of static and dynamic content. > But it made me wonder what is the effect regarding the "spoonfeeding slow > clients" scenario? I've been trying to get httpd to include a patch for the worker mpm that will handle this nicely: http://marc.theaimsgroup.com/?t=10934643134&r=1&w=2 http://marc.theaimsgroup.com/?t=10958788362&r=1&w=2 It's not quite ready for a production environment, but it'd really help if someone with a good "slow-client" test environment benchmarked it to see if it helps. -- Joe Schaefer -- 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: Threaded MPM and performance
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > It depends on many things. For example it's possible to have a simple filter > written in C, which will accept all the data from the response handler > and then spoonfeed the client, just like the proxy does. Stas, related question: I was looking over the interpreter-pool stuff in modperl_interp.c and modperl_callback.c and it looks to me like each call to modperl_callback_run_handlers grabs its own interpreter to use. Do you know if it's possible, within a single http request, for an auth handler and a response handler to use two different perl interpreters? It looks to me like it is possible. -- Joe Schaefer -- 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: SOAP::Lite, libapreq not playing together?
Ken Miller <[EMAIL PROTECTED]> writes: [...] > So, what's the solution to this? Consider upgrading to libapreq2/mp2, or use Apache::args() instead of Apache::Request::args(). The code in question *might* work with libapreq1 if you replace $r->args with $r->SUPER::args, but I'm not sure. -- Joe Schaefer -- 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: Apache::Cookie seems to read different Cookie than CGI
[EMAIL PROTECTED] writes: > Thanks Ian > > It occurred to me after I send the original email that the space may > be escaped with a +. It's not clear to me whether spaces are permitted > in cookie values The Netscape Cookie spec does not allow space chars in the raw cookie (ie the NAME=VALUE portion of the "Cookie" header). Here is the spec link: http://wp.netscape.com/newsref/std/cookie_spec.html However I suspect the space doesn't appear in the actual cookie header- it's probably a "+" there. > The weird thing is, if I set what seems to be the same Cookie > with CGI, then Apache::Cookie reads it correctly. IIRC CGI will url-encode the " " as %20, so neither " " nor "+" will appear in the actual Cookie header. Apache::Cookie is probably not translating the "+" character into a " ". Which version of Apache::Cookie are you using? -- Joe Schaefer -- 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: Apache::Cookie->new/bake broken - mod_perl 2
Dan Sully <[EMAIL PROTECTED]> writes: > I'm running into an interesting problem, using Apache::SessionManager. > > My first request to the webpage successfully generates a cookie, and I see it > in my browser's jar. The next response though, the Apache::Cookie->fetch() > gets a truncated cookie (md5 sum), and can't tie to the previous session and > creates a new one. Now, you may think this is a problem with fetching, > and not baking. > > But if I make Apache::SessionManager use CGI::Cookie for the baking, and > continue to use Apache::Cookie for the fetch, everything works fine. A > debug print ->as_string() of the Apache::Cookie->new/bake shows valid data. What is the length of the session cookie you're baking? Set-Cookie headers aren't supposed to exceed 4KB. If that's not the problem, do you notice any difference in the ->as_string() outputs for Apache::Cookie versus CGI::Cookie? -- Joe Schaefer -- 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: Apache::Cookie
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> # WORKS
> my $cookie = $ticket->cookie()->as_string();
> $r->err_headers_out->add('Set-Cookie' => $cookie);
>
> # DOES NOT WORK$ticket->cookie()->bake();
> where $ticket->cookie() is an Apache::Cookie object. This is
> the first thing in the response and is followed by:
> $r->headers_out->set(Location => '/path/');
> return Apache::REDIRECT;.
>
> Beside the fact that libapreq2 is still in development,
> is there a problem with how I am using the bake() method? Thanks in
> advance.
libapreq2 is currently using $r->headers_out instead
of $r->err_headers_out, which is why you're not seeing the
cookie on your redirect response. I think the consensus
is that this is a bug in libapreq2-2.04, but I haven't seen
any other apreq committers weigh in on the subject, so
I'm not sure.
--
Joe Schaefer
--
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: New to ModPerl 2
Kurt Hansen <[EMAIL PROTECTED]> writes: [...] > A few things that caused me more pain than I care to admit: > > 1. Apache::Cookie v2 requires an Apache::RequestRec environment > variable instead of an Apache::Request variable. Using the latter > caused a segmentation fault. If so, that's really a bug, not a portability issue. Apache::Request objects are derived from Apache::RequestRec, so it should be ok to pass them to any Apache::Cookie methods which expect an Apache::RequestRec object. Can you please show us the code which segfaults? > 3. Expires method works differently between v1 and v2 of > Apache::Cookie->new. An empty variable for -expires will default to > "now" in v2 which means the cookie won't be set since it expires > immediately. In v1, an empty -expires created a session cookie. To > get the same behavior in v2, just don't supply an -expires parameter > in new. Interesting. It looks like CGI::Cookie has the v2 behavior. $ perl -MCGI::Cookie -wle '$c = new CGI::Cookie -name=>1, -value=>2, -expires=>""; print $c->as_string' 1=2; path=/; expires=Mon, 15-Nov-2004 16:15:09 GMT I'm not sure if this is a bug in libapreq2. Any other opinions out there? -- Joe Schaefer -- 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: New to ModPerl 2
jonathan vanasco <[EMAIL PROTECTED]> writes:
> On Nov 15, 2004, at 11:18 AM, Joe Schaefer wrote:
[...]
>> Can you please show us the code which segfaults?
[...]
> sub handler
> {
> my $r = shift;
> my $req= Apache::Request->new( $r , DISABLE_UPLOADS=>1);
> my %cookiejar = Apache::Cookie::Jar->new( $req );
OK, thanks! This bug should be fixed with
the next release. It's a bit tricky to
fix this, because Apache::Request doesn't
always inherit from the environment object.
--
Joe Schaefer
--
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: Bug Report: seg fault with 1.29/Apache 1.3.33/RedHat 7.1
Tim Evans <[EMAIL PROTECTED]> writes:
> Let it build apache for me; apache's config.status says:
[...]
> "--with-layout=Apache" \
[...]
> Attaching to program: /usr/sbin/httpd, process 22798
Wrong httpd binary- the symbols in that stack trace
are from a 2.0 server. Your server's path should be
/usr/local/apache/bin/httpd
--
Joe Schaefer
--
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: Apache::Cookie->new/bake broken - mod_perl 2
Jozef Kosoru <[EMAIL PROTECTED]> writes: [...] > I would like to point out, that I have observed the > same problem with apreq2 Apache::Cookie. Sometimes browser gets a > truncated cookie and sometimes even a garbage cookie data. This bug should be fixed in the current svn trunk, thanks to Bojan's recent patch. -- Joe Schaefer -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl marketing
Stas Bekman <[EMAIL PROTECTED]> writes: > Dan Brian wrote: >>> So far only a few people actually did something (publishing articles, >>> helping to update and improve the website), the rest are just talking. >> Many are also spending a lot of time influencing their own spheres >> (businesses, peers) to learn and actually adopt the technology. I think >> that's some of the most valuable advocacy. > > That's true. Unfortunately those are unseen heros, as we can't really > know whether something is going on or not. Folks, I realize it may be too late to stop the impending email avalance, but *please* move this exciting discussion to the mod_perl advocacy list [1]. Threads with "marketing" in the subject line really belong over there, not here. [1]- [EMAIL PROTECTED] -- Joe Schaefer -- 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: [libapreq] could not create/open temp file
Brian Hirt <[EMAIL PROTECTED]> writes:
> all of a sudden i'm getting '[libapreq] could not create/open temp
> file'. Searching on google, i came across a patch stan posted to give
> a more meaningful error message, but somehow it never made it into the
> CVS tree. (i've got libapreq1.2 installed)
Thanks for the reminder! I rolled 1.3_rc1 earlier today, so does
anybody mind if I include the following patch in 1.3_rc2?
Index: c/apache_request.c
===
RCS file: /home/cvs/httpd-apreq/c/apache_request.c,v
retrieving revision 1.26
diff -u -r1.26 apache_request.c
--- c/apache_request.c 12 Jul 2003 17:42:00 - 1.26
+++ c/apache_request.c 25 Sep 2003 19:44:47 -
@@ -56,6 +56,8 @@
* University of Illinois, Urbana-Champaign.
*/
+#include
+#include
#include "apache_request.h"
#include "apache_multipart_buffer.h"
int fill_buffer(multipart_buffer *self); /* needed for mozilla hack */
@@ -491,7 +493,9 @@
}
if ( tries == 0 || (fp = ap_pfdopen(r->pool, fd, "w+" "b") ) == NULL ) {
- ap_log_rerror(REQ_ERROR, "[libapreq] could not create/open temp file");
+ ap_log_rerror(REQ_ERROR,
+ "[libapreq] could not create/open temp file: %s",
+ strerror(errno));
if ( fd >= 0 ) { remove(name); free(name); }
return NULL;
}
--
Joe Schaefer
[ANNOUNCE] libapreq 1.3_rc2 available for testing
1.3_rc2 is httpd-apreq's current cvs; the corresponding tarball is now available at http://httpd.apache.org/~joes/libapreq-1.3_rc2.tar.gz The only change made since 1.3_rc1 is the addition of Stas' old logging patch, which was mentioned on the modperl list yesterday. I've tested it on RH linux against 5.8.0 and 5.8.1. Please give it a try. Thanks! -- Changes since the 1.2 release: =over 4 =item 1.25 - August 23, 2003 Michael G. Schwern's "play it safe" patch to c/Makefile.PL (applied patch submitted by Steve Hay). See http://marc.theaimsgroup.com/?l=perl5-porters&m=105981649201380&w=2 http://marc.theaimsgroup.com/?l=apreq-dev&m=106146287323705&w=2 for details. [joes] =item 1.24 - August 23, 2003 Applied Steve Hay's Request.pm doc patch explaining the tempnam() dependence for C's TEMP_DIR option. [joes] =item 1.23 - July 10, 2003 Applied Graham Clark's patch to cleanup apache_request.h macros. Added missing doc credits for Steve Hay in Request.pm. [joes] =item 1.22 - July 5, 2003 Open uploaded files with binary mode (relevant for Perl > 5.7), so as to be able to get the correct sizes on systems where such a mode makes a difference. Thanks to Steve Hay for first pointing out this problem. [randyk] =item 1.21 - June 25, 2003 Fix memory access problem with TEMP_DIR - see http://marc.theaimsgroup.com/?l=apreq-dev&m=105647058517842&w=2 Thanks to Jay Buffington for the spot. [joes]
[ANNOUNCE] libapreq-1.3 released
The uploaded file libapreq-1.3.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JO/JOESUF/libapreq-1.3.tar.gz size: 279075 bytes md5: b40854e91a6210a3af47ef9a875e It is also available through an apache mirror near you: http://www.apache.org/dyn/closer.cgi/httpd/libapreq -- Changes from version 1.2: =item 1.25 - August 23, 2003 Michael G. Schwern's "play it safe" patch to c/Makefile.PL (applied patch submitted by Steve Hay). See http://marc.theaimsgroup.com/?l=perl5-porters&m=105981649201380&w=2 http://marc.theaimsgroup.com/?l=apreq-dev&m=106146287323705&w=2 for details. [joes] =item 1.24 - August 23, 2003 Applied Steve Hay's Request.pm doc patch explaining the tempnam() dependence for C's TEMP_DIR option. [joes] =item 1.23 - July 10, 2003 Applied Graham Clark's patch to cleanup apache_request.h macros. Added missing doc credits for Steve Hay in Request.pm. [joes] =item 1.22 - July 5, 2003 Open uploaded files with binary mode (relevant for Perl > 5.7), so as to be able to get the correct sizes on systems where such a mode makes a difference. Thanks to Steve Hay for first pointing out this problem. [randyk] =item 1.21 - June 25, 2003 Fix memory access problem with TEMP_DIR - see http://marc.theaimsgroup.com/?l=apreq-dev&m=105647058517842&w=2 Thanks to Jay Buffington for the spot. [joes]
Re: Problem with libapreq + possible fix
Shannon D Schlueter <[EMAIL PROTECTED]> writes: > While trying to install the GMOD/CMAP perl modules, I encountered a > problem where Apache::Cookie->new(...) was returning an object method > not found. As per the suggestion at > http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w=2 > I altered the Makefile.PL files in the Request and Cookie > directories. This seems to have fixed the problem. Great! What operating system and perl version are you running? > We found this using the latest CPAN libapreq (1.3) and perl 5.8.1. > > Was this an appropriate patch? > > Have I messed something else up by doing this? The patch is correct. The problem is that the apreq-dev folks don't know if it works on OSX or not, so it hasn't been applied. -- Joe Schaefer
[ANN] libapreq2-2.01-dev-rc1 release candidate #1
The first developer release of libapreq2 is underway. This package provides the Perl modules Apache::Request and Apache::Cookie for modperl-2, and requires the following: apache2 w/ mod_so: 2.0.46 libapr: 0.9.4 libaprutil: 0.9.4 modperl2: 1.99_09 perl: 5.6.1 Apache::Test: 1.03 ExtUtils::XSBuilder: 0.23 Release Candidate #1 is at http://httpd.apache.org/~joes/libapreq2-2.01-dev-rc1.tar.gz Please give it a try and report any success/failures to the [EMAIL PROTECTED] list. Thanks! == @section v2_01_dev Changes with libapreq2-2.01-dev - October 26, 2003 - C API [joes] Incorporate libapreq_cgi into libapreq2 as the default environment, and add apreq_env_t and initializer apreq_env_module() to manage the environment at runtime (determining the environment at load-time was problematic on non-ELF systems). @section v2_0_0 Changes with libapreq2-2.00-dev - October 24, 2003 - C API: libapreq_cgi.c [randyk, joes] CGI environment defined by env/libapreq_cgi.c is functional (with tests added to env/t). This library may soon be incorporated directly into libapreq2 as a default enviroment. - October 23, 2003 - C API: mod_apreq.c [joes] Added ctx->saw_eos to ensure we don't read from upstream filters after receiving an eos bucket. Otherwise it was possible for two eos buckets to appear when a prefetch read is involved, which breaks other modules like mod_proxy. This bug was uncovered by Philippe Chiasson. mod_apreq's apreq_env_majic_number bumped to reflect the added fixes. - October 17, 2003 - configure: --enable-perl-glue [joes] The --enable-perl-glue option integrates the perl glue into the normal Unix build cycle. It is disabled by default, but is silently reenabled if the user configures the source tree via Makefile.PL. - October 14, 2003 - C API [joes] Added apreq_header_attribute() and fixed mfd parser to allow "charset" attribute to appear in the Content-Type header. Sven Geisler points out that Opera 7.20 does generate such headers. - October 14, 2003 - C API [joes] Added versioning API following http://apr.apache.org/versioning.html apreq_env renamed apreq_env_name, and apreq_env_magic_number added to provide versioning for environments (modules). The header files are now installed to "include/apreq2", and the library is renamed "libapreq2". Also added an apreq2-config script based on apu-config. - October 8, 2003 - configure: static mod_apreq.c [Bojan Smojver, joes] Add --with-apache2-src configure option, along with --with-apr-config and --with-apu-config, and provide support for compiling mod_apreq into httpd as a static apache module. - October 1, 2003 - C API: mod_apreq.c [joes] Support for internal redirects added to the mod_apreq filter. This ensures any POST data prefetched in the main request gets passed along to the subrequest handler(s). - July 18, 2003 - C bugfix: apreq_decode [Graham Clark] If the source and destination strings are represented by the same pointer - e.g. if called as apreq_unescape(s) - string s is modified incorrectly in general. Patch includes new unit test. - July 16, 2003 - Perl API [joes] Added $req->parse, $req->status, & "preparse" logic to $req->param & $req->upload. - July 16, 2003 - C API [joes] Added "preparse" logic to apreq_params & apreq_uploads to bring behavior in line with libapreq-1.x. - July 15, 2003 - C API [joes] Dropped param->charset. Make apreq_brigade_concat public, so mod_apreq can use it for its ctx->spool brigade. - July 14, 2003 - Documentation [joes] Updated Cookie_pod to reflect API changes over v1.X. - June 30, 2003 - Documentation [joes] Added doxygen links to Apache::Request and Apache::Cookie perl docs. - June 30, 2003 - C API [joes] Added apreq_copy_brigade(bb) to apreq.h. - June 27, 2003 - C API [joes] The new filter-based design required a complete departure from libapreq-1.X codebase. libapreq-2 is based solely on APR, and to be fully functional, requires a supporting environment similar to Apache-2. A person wishing to port libapreq-2 to a new environment needs to provide definitions for the declarations in apreq_env.h. - June 27, 2003 - Perl API [joes] Aggregates are always collected into an APR::Table-based package. New table packages: Apache::Cookie::Table, Apache::Request::Table, and Apache::Upload::Table. - June 27, 2003 - Perl API [joes] Apache::Cookie->fetch now requires an "environment" argument ($r). Its return value is blessed into the Apache::Cookie::Jar class. - June 27, 2003 - Perl API [joes] Two new request lookup functions: -# $req->args - param lookup using only the query string -# $req->body - param lookup using only the POST data -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Request->instance()
Eric Sammer <[EMAIL PROTECTED]> writes: > I'd rather not paint myself into the proverbial corner if > Apache::Request->instance() is being deprecated. There are no plans whatsoever to deprecate instance() from the Apache::Request 1.X that comes in the libapreq-1.X package. The APIs for 1.X are stable, and very unlikely to change at all. However, the 2.X line is a completely different implementation targeted for a different server architecture (apache 2). It's unlikely that modules written for Apache::Request 1.X will be 100% source-compatible with Apache::Request 2.X. The 1.X and 2.X lines should be considered parallel versions, since that is how they are being maintained and developed. > Obviously, this is MP1.x, Apache 1.3.x (on Gentoo Linux, for > those interested). For Apache2, Apache::Request->new will always reference the appropriate per-request data; instance() isn't needed there, so it won't be included in the 2.X releases. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: oddity (bug?) with param
Bruce Langlois <[EMAIL PROTECTED]> writes:
> I have encountered what I consider a bug in the 'param' method
> of Apache::Request in mod_perl 1. The method returns a
> list of parameters, or a '0' if no parameters are found.
[...]
> The documentation does not specify what the actual return should be in
> the case where there are no parameters, but it seems to me that an
> empty list would be more appropriate than a '0'.
Returning '0' instead of an empty list is a bug.
See if this patch helps:
Index: Request/Request.xs
===
RCS file: /home/cvs/httpd-apreq/Request/Request.xs,v
retrieving revision 1.37
diff -u -r1.37 Request.xs
--- Request/Request.xs 5 Jul 2003 02:35:20 - 1.37
+++ Request/Request.xs 11 Nov 2003 21:24:30 -
@@ -424,6 +424,7 @@
I32 i;
array_header *arr = ap_table_elts(req->parms);
table_entry *elts = (table_entry *)arr->elts;
+XSprePUSH;
for (i = 0; i < arr->nelts; ++i) {
if (elts[i].key && strcaseEQ(elts[i].key, key))
XPUSHs(sv_2mortal(newSVpv(elts[i].val,0)));
@@ -449,6 +450,7 @@
I32 i;
array_header *arr = ap_table_elts(req->parms);
table_entry *elts = (table_entry *)arr->elts;
+XSprePUSH;
for (i = 0; i < arr->nelts; ++i) {
I32 j;
if (!elts[i].key) continue;
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] libapreq2 segmentation fault
Wolfgang Kubens <[EMAIL PROTECTED]> writes:
> Has anyone any idea?
See if this patch helps. Do a
% make clean && make test
in the base directory after applying the patch, so the perl glue
gets rebuilt properly with the patched Apache__Cookie.h.
Index: glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h
===
RCS file: /home/cvs/httpd-apreq-2/glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h,v
retrieving revision 1.15
diff -u -r1.15 Apache__Cookie.h
--- glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h 17 Oct 2003 14:23:29 -
1.15
+++ glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h 12 Nov 2003 15:28:34 -
@@ -154,7 +154,7 @@
XSRETURN_UNDEF;
c = apreq_value_to_cookie(apreq_xs_sv2(cookie,ST(0)));
-p = apreq_env_pool(apreq_xs_sv2env(ST(0)));
+p = apreq_env_pool(apreq_xs_sv2env(SvRV(ST(0;
for (j = 1; j + 1 < items; j += 2) {
STRLEN alen, vlen;
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
[ANN] libapreq2-2.02-dev release candidate #1
2.02-dev will be a maintenance release to fix the reported segfaults with Apache::Cookie::new(). Please give this candidate a try at http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz == @section v2_02_dev Changes with libapreq2-2.02-dev - November 12, 2003 - Perl API [joes] Fix bogus pool/cookie initializers in Apache::Cookie::set_attr(), which caused Apache::Cookie::new to segfault. Bug first reported to modperl list by Wolfgang Kubens. Thanks! -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANN] libapreq2-2.02-dev release candidate #1
Wolfgang Kubens <[EMAIL PROTECTED]> writes: [...] > unfortunatelly i was not able to reply earlier. Thanks for your fix from > this morning. Just for your info, after i applied your changes it seems > to be work. The error does not occurs again. Great! However, after further testing, it appears that fix alone was insufficient. This release candidate is the best version available at the moment. > Nevertheless i will download the current release as soon as possible ;-) Outstanding- and thanks for being one of the early adopters of libapreq2! The best way for the package to improve now is for folks to start exercising the code. libapreq2 is a full order of magnitude more complex than libapreq1, which is why there are so many tests (over 100) already in the package. But there's plenty of room for more, especially wrt the perl modules. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r losing its class membership
Stas Bekman <[EMAIL PROTECTED]> writes: > You need to show us what PrintMe::Transaction2 does. It seems that you are > trying to subclass 'Apache' (which is what $r is blessed into). May be you > didn't do the proper subclassing. Maybe something funky's going on with his handler's prototype? IIRC a ($$) prototype will cause modperl to put the handler's package name in the first argument. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Geoffrey Young <[EMAIL PROTECTED]> writes: > for the record, this is exactly how apache behaves for people writing > C modules > - it expects a handler to return OK, DECLINED, DONE, or > _some_http_status_all_of_which_mean_"error" > > so, I'd rather not go back to 200 == OK. not only does this make writing > handlers in perl different than C, but is also creates a problem for > people who use mod_perl to drive protocols other than HTTP, where 200 > might well mean something entirely different. +1. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [RELEASE CANDIDATE] libapreq 1.33 (mp1)
Stas Bekman <[EMAIL PROTECTED]> writes: > If it is implemented already, then it's our *bug* and we just need to > release Apache-Test with a correct META.yaml. Either way, this is not a showstopper for apreq. Here's my +1 for libapreq-1.33. -- Joe Schaefer -- 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: [mp2] how to redirect POST data
Beberle <[EMAIL PROTECTED]> writes: > Right, that's exactly the problem I'm trying to work > around. Once I've read the POST data, is there some > way to re-POST it? Not sure this is addressing your particular problem, but let me try to explain how Apache::Request tries to resolve this sort of thing in mp2. apache 2.x has filters, which can be plugged into the I/O chain just about anywhere. So if you think of the HTTP request as a pipeline between the user-agent and apache's response-handler [user-agent] -> [intermediate web proxies] -> [apache server] -> [connection filters] -> [protocol filters] -> [request filters] -> ^ [response-handler] ^ ^ (mod_apreq) mod_apreq is a request filter which gets inserted into the pipeline whenever someone makes a certain libapreq2 library function call. In the mp2 case, that happens whenever someone invokes Apache::Request::new. Through mod_apreq, libapreq2 is able to parse the POST data without removing the data from the pipeline. If it needs to, mod_apreq will drive the pipeline to pull more data through, but the data will remain in the pipeline for later filters/handlers to see. It's designed this way to allow Apache::Request to be usable in any pre-response-handler phase without losing the POST data. -- Joe Schaefer -- 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: [mp2] how to redirect POST data
Beberle <[EMAIL PROTECTED]> writes: > Ok, I'm getting closer but still not there yet. I've > added a filter like so: [...] > I've been able to successfully capture the POST data > without removing it from the chain. Problem is, it's > too late. From what I've been able to gather from > printing to the error log, the chain looks like this: > > PerlTransHandler --> PerlAccessHandler --> PerlHandler > --> PerlInputFilterHandler > > I thought the filter was accessed before the > response-handler. Request filters aren't normally inserted into the filter chain until the response-handler is ready to run. mod_apreq is an exception, and it's quite tricky to pull this off without breaking lots of other things. > What am I doing wrong? What you're trying to do isn't a simple thing, even if you're familiar with apache2's innards. The input filter system wasn't really designed to encourage people to do what you're doing. So, have you tried using Apache::Request yet? -- Joe Schaefer -- 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: compile problems
"Barksdale, Ray" <[EMAIL PROTECTED]> writes: [...] > /usr/bin/ld: > /usr/local/lib/perl5/5.8.5/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoa > der.o): relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/perl5/5.8.5/x86_64-linux/auto/DynaLoader/DynaLoader.a: could > not read symbols: Bad value I think this means Fedora's DynaLoader.a file needs to be (re)compiled with -fpic (or -fPIC). Look for "-Duseshrplib" and/or "cccdlflags='-fPIC'" in perl -V. -- Joe Schaefer -- 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: [RELEASE CANDIDATE] libapreq 1.33 (mp1)
Stas Bekman <[EMAIL PROTECTED]> writes: > Please test this package: http://apache.org/~stas/libapreq-1.33.tar.gz > (Apache::Request for mod_perl 1.x) and report any problems here. Builds fine for me on debian woody. However the CPAN dependencies for Apache::Test (a listed prereq) are currently b0rked, because CPAN thinks mod_perl-2.0.0-RC1 provides it: % perl -MCPAN -e shell i /Apache::Test/ ... Module Apache::Test(G/GO/GOZER/mod_perl-2.0.0-RC1.tar.gz) -- Joe Schaefer -- 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: $bb,$b, PerlOutputFilterHandler and $rv = $f->pass_brigade($bb);
"eps com estem" <[EMAIL PROTECTED]> writes:
[...]
> 1)- First thing is that if i am creating a new bucket for a new
> brigade, the line
>my $b = APR::Bucket->new($bb->bucket_alloc,$data);
> should be
>my $b = APR::Bucket->new($bb_ctx->bucket_alloc,$data);
> or that's what i think(?).
Makes no difference; they all should reference the
same internal allocator (f->c->bucket_alloc).
> With this change in the first codes the situation however doesn't
> change.
>
> 2)- Second thing is that, in a try to "finish" the transaction i
> wanted to create an eos stream. Docs say
> use APR::Bucket ();
> use Apache::Connection ();
> my $ba = $c->bucket_alloc;
> my $eos_b = APR::Bucket::eos_create($ba);
Syntactically correct, but normally you shouldn't create
your own eos bucket. The upstream filter will eventually
send one to your filter, so its better to just pass *that*
one along when it comes.
> so
> my $eos_b = APR::Bucket->eos_create($f->c->bucket_alloc);
> should work ... or not ...
No that doesn't work. The error message is correct,
eos_create only takes one argument: an APR::BucketAlloc
object.
> If i put
> my $eos_b = APR::Bucket::eos_create($f->c->bucket_alloc);
> there's no more Internal Error, but page appears (after 8-10 seconds)
> truncated.
Right. Your filter may be invoked multiple times
for a single request. By inserting the eos
bucket too soon, you wind up confusing both apache
and the browser. The eos bucket tells downstream
filters that no more content will be coming, so
apache won't send any more data even if the browser
is expecting it.
> a) :: is not equal to ->? i though yes but i have not verified
They're different. The -> is a (class) method call,
so perl will do an OO lookup for the proper method
and adjust @_ accordingly. In your example, these
two (erroneous) invocations are the same
APR::Bucket->eos_create($data)
APR::Bucket::eos_create("APR::Bucket", $data)
> b) an eos ends only the brigade, isn't it? or it ends the filter?
Ends the *request*. Each brigade / filter invocation
represents only a part of the full request.
>
> 3)- Third, i think $bb should be destroyed instead of cleaned up, am i
> right?
Both the brigade and the buckets within it will be
cleaned up automatically when the connection dies.
It's ok to cleanup/destroy a bucket brigade before that,
but you don't need to worry about this unless you
really want to.
I suggest you try working through the example at
http://perl.apache.org/docs/2.0/user/handlers/filters.html
#Bucket_Brigade_based_Output_Filters
>
If you have problems/questions with the documented
examples, report them and the docs will likely improve.
Best wishes.
--
Joe Schaefer
--
Report problems: 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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes:
> if ($apache->content_type() eq 'multipart/form-data') {
No. $r->content_type() represents the response (outgoing) header,
not the request (incoming) header:
http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html#C_content_type_
>
> While i'm able to read all text params, there are no entries in $uploads.
No clue. I'd like to help, but puzzling out the problem
from your code snippets isn't sufficient enticement. Please
post full details, including a complete package+handler with
configuration info and error-log output. Maybe it's an apreq
bug, maybe it isn't. But if I can't reproduce your problem
locally, there's not much I can do other than offer you my
sympathy.
--
Joe Schaefer
--
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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes:
> if ($info->{content} =~ /.*multipart.*/) {
> my $mm =Apache::Request->new($apache,POST_MAX=>5); #50k max
> my $uploads =$mm->upload();
> my $table =$mm->param(); #en teoria els uploads ja no estan
Try switching the order:
my $table =$mm->param(); #en teoria els uploads ja no estan
my $uploads =$mm->upload();
If that fixes your problem, there's a bug in $mm->upload()
that we need to fix.
--
Joe Schaefer
--
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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes: > A) > Switching the order makes no difference. Params catch 6 args and > uploads none. Results are the same with the last versions installed. Ok, happily that eliminates one possibility. Another possibility is that apreq's mfd parser is having a problem detecting the file upload field. Another would be that the parser is actually operating correctly, but the user agent is screwing up the form submission for your file field. Another possibility is that the html form is screwed up somehow. What does the complete html form look like? Which browsers (and versions) are you testing? -- Joe Schaefer -- 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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes:
[...]
>
>
>
>
>
> And this is the error.log
>
> Apache::Upload::Table=HASH(0x11ee1c4) 0 at
> f:/tools/apache2/lib/perl/Blogum/Generic.pm
> line 208.
> Apache::Request::Table=HASH(0x1304a50) 2 at
> f:/tools/apache2/lib/perl/Blogum/Generic.pm
> line 209.
> hola = eps at f:/tools/apache2/lib/perl/Blogum/Generic.pm line 219.
> eps = aaaUntitled-1.gif at f:/tools/apache2/lib/perl/Blogum/Generic.pm line
> 219.
>From this, it looks to me like libapreq is parsing the POST data correctly
(the gif filename showing up as the eps param value is a tell-tale sign that
the upload was parsed ok). So the now question is: why isn't $mm->upload()
detecting that body table entry as being an upload?
See if you can get at the file upload in another way, like
my $upload = $req->upload("eps") or
die "Can't locate 'eps' upload";
Also see what happens if you change the form to just a single file
upload, with no other fields.
--
Joe Schaefer
--
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: libapreq2 upload question
Joe Schaefer <[EMAIL PROTECTED]> writes:
> From this, it looks to me like libapreq is parsing the POST data correctly
> (the gif filename showing up as the eps param value is a tell-tale sign that
> the upload was parsed ok). So the now question is: why isn't $mm->upload()
> detecting that body table entry as being an upload?
I found the bug, thanks eps for helping to track it down! Here's the
patch against apreq/trunk (some of the upload-related table callbacks
were emitting the wrong return value, which prematurely terminates the
upload search).
Index: src/apreq_params.c
===
--- src/apreq_params.c (revision 112718)
+++ src/apreq_params.c (working copy)
@@ -21,9 +21,8 @@
#define MAX_LEN (1024 * 1024)
#define MAX_BRIGADE_LEN (1024 * 256)
-#define MAX_FIELDS (200)
#define MAX_READ_AHEAD (1024 * 64)
-
+
APREQ_DECLARE(apreq_param_t *) apreq_make_param(apr_pool_t *p,
const char *name,
const apr_size_t nlen,
@@ -147,7 +146,7 @@
apr_array_header_t *arr = data;
*(apreq_param_t **)apr_array_push(arr) =
apreq_value_to_param(apreq_strtoval(val));
-return 1;
+return 1; /* keep going */
}
@@ -323,7 +322,7 @@
apreq_param_t *p = apreq_value_to_param(apreq_strtoval(val));
if (p->bb)
apr_table_addn(t, key, val);
-return 0;
+return 1; /* keep going */
}
@@ -354,10 +353,10 @@
apreq_param_t **q = data;
if (p->bb) {
*q = p;
-return 1; /* upload found, stop */
+return 0; /* upload found, stop */
}
else
-return 0; /* keep searching */
+return 1; /* keep searching */
}
--
Joe Schaefer
--
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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes:
> my $info = {};
> $upload->slurp($info->{eii});
> $info->{eii} contains nothing.
>
> This is the same that happened in $r->read function, that was fixed
> two seconds after :)
Here's a patch for $upload->slurp, see if it helps:
Index: glue/perl/xsbuilder/Apache/Upload/Apache__Upload.h
===
--- glue/perl/xsbuilder/Apache/Upload/Apache__Upload.h (revision 112718)
+++ glue/perl/xsbuilder/Apache/Upload/Apache__Upload.h (working copy)
@@ -283,6 +283,7 @@
data[len_size] = 0;
SvCUR_set(ST(1), len_size);
SvPOK_only(ST(1));
+SvSETMAGIC(ST(1));
s = apr_brigade_flatten(bb, data, &len_size);
if (s != APR_SUCCESS) {
APREQ_XS_THROW_ERROR(upload, s, "Apache::Upload::slurp",
--
Joe Schaefer
--
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: libapreq2 upload question
"eps com estem" <[EMAIL PROTECTED]> writes: [...] > One last question, would you use libapreq2 to handle all GET > and POST data or only the multipart-POST data?? It's designed to be usable for all GET / POST data. The Content-Types it currently understands are application/x-www-form-urlencoded multipart/form-data multipart/related The first two are what HTML forms typically use, but we've also laid enough groundwork within libapreq2 to support newer specs like XForms and WHATWG once browsers start implementing them. libapreq2 provides a C API to extend/modify the parser list, so you can even extend it yourself if apreq-dev@ isn't extending it fast enough for you. > I mean, what's the intention of libapreq to be? libapreq2 is intended to provide a common request parsing library for all apache2 modules (not just a "faster CGI.pm"). There are already a few C modules (mod_spin is a nice example) that use libapreq2. The upshot is that such modules will all share the *parsed* POST data, without stealing the *raw* POST data from other modules. -- Joe Schaefer -- 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: Slashdot | Help Test mod_perl 2 Release Candidates
"Perrin Harkins" <[EMAIL PROTECTED]> writes: [...] > I'm not wild about the "use Apache2" solution either, but I just don't use > it. Wouldn't it be easier Easier than what? Right now mp2 is supposed to autodetect a prior mp1 install and adjust accordingly. I don't know how parallel installations could be made any easier. The Apache2 thingy works well IMO, it just seems that some folks aren't familiar with it. Randal's complaints about mucking with the doc toolchain are all addressable within the current framework. The basic idea is that if you're using both mp1 and mp2, perldoc doesn't see the mp2 docs unless you supply the Apache2:: prefix. I'm not sure about how the manpages are installed yet, but I think we could do the same thing for those if it's needed. The real significant issue to address, IMO, has to do with CPAN's indexing of the Apache:: modules common to both mp1 and mp2 core distros, because those packages set the underlying apache[12] architecture. That issue is being debated in a few different forums, but I think the [EMAIL PROTECTED] list is the best place for it. -- Joe Schaefer -- 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: Slashdot | Help Test mod_perl 2 Release Candidates
Geoffrey Young <[EMAIL PROTECTED]> writes: > Perrin Harkins wrote: >>>however, it's not as simple as renaming everything Apache2::*. why? it >>>just doesn't scale well. for example, there are _already_ compat issues >>>between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would >>>need Apache2::* for modules that use the Apache 2.0 API and Apache2.2::* >>>for >>>those that use the 2.2 API. then perhaps Apache3::* someday, etc... >> >> >> I don't really see what the problem is with that. C libraries seem to do >> it that way without too much trouble. What would be the harm in having >> Apache2_2:: and Apache3:: and Apache27:: etc.? It's no worse than saying >> "I want Apache::Foo, but from the 2.2 distribution." > > well, I agree that doing it that way isn't the _worst_ thing that could > happen, It sure might be, given the apparent confusion between "interface compatibility" and "platform support". Unlike the 1.3|2.0 situation, it's quite possible that a single mp2 source distro will be able to support both apache 2.0 and 2.2; moreover it would make very little sense to support them in a parallel install. If so, users will have to decide which server platform (2.0 or 2.2) they want their mp2 installation to use. Module authors requiring a specific 2.x platform can just *test for it*. If their latest version doesn't support as many platforms as mp2 does, either ask CPAN for multi-version indexing, or just document the issue. But asking the community to embed every incompatible server platform in the package system, just to communicate a platform specification to CPAN? Please, lets not do that. The reason for Apache2.pm is to support parallel installation, nothing more. My only gripe with the mp2 release candidates is that I would have liked to see a few production mp2 releases on CPAN before its mp1 indexing starts to disappear. -- Joe Schaefer -- 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: Slashdot | Help Test mod_perl 2 Release Candidates
Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: >> My only gripe with the mp2 >> release candidates is that I would have liked to see a few production >> mp2 releases on CPAN before its mp1 indexing starts to disappear. > > Sure, you can ask Andreas to not index mp2 and any other 3rd party > modules. But why making mp2 users suffer? > > I still can't understand the definition of 'a few production > releases'. How will you know when it's OK to switch the direction of > the blade and make the mp1 users suffer? When the conversation changes from "Why did you guys do that?" to "When will you guys do that?". By putting one or two official mp2 releases "out there" that don't have the mp1 reindexing snafu, we're saying "mp2 is ready to rock now, but you may still have to dig a little bit to find it on CPAN. However, that'll be changing in the next release or so." It may be a bit easier to get our volunteer "broadcast network" to lament mp1's eventual passing, yet still deliver the message above faithfully. I'm not sure that will happen with the current release plan, and that's not a great way to kick off mp2's coming-out party. > Will you then go and notify the mp2 users: "we favor you now, please > come back and use the CPAN tools" and notify the mp1 users: "excuse > us, but mp1 was phased out, and we no longer support it via CPAN, so > please find and download modules manually from now on" Nope, not at all. It's about giving the entire community a chance to embrace the production version of mp2, and also to disseminate its implications for mp1 far and wide. Nobody's kicking mp1 out the door, but without some grace period to digest the changes, I'm worried many people may react that way. > Originally the _RC1 vs -RC1 was a slip, but I'm glad that it has > happened earlier and not when 2.0.0 was released, since it has raised > the problems earlier. And since we have mp2.0.0 scheduled for the > beginning of January, that RC1 slip doesn't make much difference > time-wise. +1, it's good to discuss everything now, rather than after the release. -- Joe Schaefer -- 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: Slashdot | Help Test mod_perl 2 Release Candidates
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > I'm not against from hiding mp2 from index. I just don't > understand how does it make the mp2.0 release any better? > >"Hey, modperl 2.0 is available, but you can't get it > from CPAN using the familiar tools. Hiding it entirely isn't what I have in mind, just the modules common to both mp1 and mp2. Indexing everything else, especially Apache2 and the new ModPerl::* stuff, might be a workable compromise. [...] > And hide the real problem with CPAN again. People will react > either way, since this suggestion doesn't remove the problem, it > just re-throws it in a difference direction. It also allows time for the now-manifest itching to become productive scratching. Maybe CPAN gets fixed, maybe folks upgrade their mp1 modules to support both mp1 and mp2, or maybe those folks just migrate wholesale to mp2. Or maybe some enlightened person will wander in and show us all a demonstrably better way to handle the CPAN situation. Or maybe I'm wrong, and the extended itching turns out to be just more bitching. Who knows? -- Joe Schaefer -- 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: compile problems
"Barksdale, Ray" <[EMAIL PROTECTED]> writes:
[...]
>> >>From this:
>> > Total: 608169K ( 580M) size, 145465K ( 139M) approx
>> real size (-shared)
>> >
>> > down to this:
>> > Total: 600129K ( 572M) size, 131588K ( 125M) approx
>> real size (-shared)
Are you sure this isn't just some wackiness in the virtual
memory reporting on amd64? I've been using debian amd64
for a while, and the VSZ numbers have been consistently absurd
for all my processes (eg they often total to considerably more
than my available RAM + swap). For instance here's my emacs
on debian woody (32bit):
% emacs -nw &
[1] 13029
% ps u
USER PID %CPU %MEM VSZ RSS ...
joe 13029 0.0 0.3 8020 3208 ...
and on amd64:
% ps u
USER PID %CPU %MEMVSZ RSS ...
joe 21248 0.0 0.2 29144 4336 ...
The libraries emacs links to are basically the same:
% ldd `which emacs` | perl -alpe '$a += `du -bL $F[2]`} $_=$a;{'
=>
5060944 bytes for 64bit,
4063232 bytes for 32bit.
So the libraries are ~25% larger, the emacs binary
is ~60% larger (3985408 vs 6633208), but ps reports
almost a four-fold increase in VSZ. Go figure.
Here's a possibly relevant link I found while googling
for an answer:
https://www.redhat.com/archives/amd64-list/2004-September/msg3.html
--
Joe Schaefer
--
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: Slashdot | Help Test mod_perl 2 Release Candidates
"Perrin Harkins" <[EMAIL PROTECTED]> writes: > Stas Bekman said: >> In fact Perrin gave a perfect counter-example, while looking for an >> example. The fact is C libraries *do not* embed version numbers in their >> API. > > Sure they do, when they change the API significantly: SQLite2, Gtk2, > libxml2. Separate API, manpages, headers, etc. Not quite. There's a difference between appending a version number to library name, and embedding a version number in the function names. The former is standard practice nowadays because we distribute our C libraries to other developers, and telling a C compiler which API you want to you want to compile against can be a royal PITA without versioning both the soname and INC path. The latter is what symbol versioning solves, which works fine when you're distributing to end-users only. But nobody sane mangles C function names by actually embedding version numbers in them; the linker's toolchain is expected to work that out (with a few hints here and there). -- Joe Schaefer -- 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
