Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: > Got a bit of a weird set of behaviour with a mod_perl Apache::Registry > type script. [snip] > More information about this error may be available > in the server error log. [snip] > Anyone got any ideas? What does it say in the error_log? 73, Ged.
Re: Possible bug with a 206 Partial Response
Good Point. Forgot to mention that the error log is completely empty. :) Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Got a bit of a weird set of behaviour with a mod_perl Apache::Registry type script. [snip] More information about this error may be available in the server error log. [snip] Anyone got any ideas? What does it say in the error_log? 73, Ged.
ANNOUNCE: CGI::Application 3.0
Version 3.0 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.5: - Changed the run() method to use Perl's built-in dynamic method call for all run modes, whether by name or by code ref. This is intended to improve run-time performance somewhat. Thanks to Darin McBride for this patch. - Added new override-able method cgiapp_get_query(). This method is called when CGI::Application first needs access to the CGI query object. By default, this is a CGI.pm object. It is possible to override the cgiapp_get_query() method to return an object of some other module besides CGI.pm, providing that it is sufficiently compatible. Thanks to Eric Andreychek for the suggestion and his help troubleshooting the code. - Changed run_modes() method to allow list of run-modes to be designated via an array reference. This will automatically create a run-modes table which maps from a run-mode to a run-mode method of the same name. Bumped major revision number to reflect this significant change in functionality. - Clarified license for module (GPL or Artistic). Included licenses in distribution package. Read the recent "Using CGI::Application" article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of "Run-Modes." Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single "Application Module" which is a Perl module. In your web server's document space there is an "Instance Script" which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to "[EMAIL PROTECTED]".
Re: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
Hi Stas, Thanks for your reply. The file perms are correct and nothing is printed to the logs. The scripts do run. If you write a script with a redirect in it for instance, the redirect is made. They just don't seem to print anything to stdout. Regards, George Savvides. Stas Bekman wrote: > > What has error_log to say about this? Do you have the file perms right? > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: > Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re[2]: cgi and mod_perl-1.26, Apache-1.27, perl-5.8.0, FreeBSD failwith 'The document contained no data'
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Hi George,
I've not seen any of this thread other than what's
below, but have you had all the headers output correctly?
Try running this after setting $url, and see what you get:
use LWP::UserAgent;
$url = "http://195.117.126.24";;
$ua = LWP::UserAgent->new;
$req = new HTTP::Request('GET', $url); # Format URL request
$res = $ua->request($req);
if (not $res->is_success()) {
die "...failed:\n" . $res->error_as_HTML
}
warn $res->headers_as_string;
warn $res->content;
#open OUT, ">/test.html";
#print OUT $res->content;
#close OUT;
exit;
Lee
On Sunday, February 2, 2003 at 7:42:12 PM, you wrote:
GS> Hi Stas,
GS> Thanks for your reply.
GS> The file perms are correct and nothing is printed to the logs.
GS> The scripts do run. If you write a script with a redirect in it
GS> for instance, the redirect is made. They just don't seem to
GS> print anything to stdout.
GS> Regards, George Savvides.
GS> Stas Bekman wrote:
>>
>> What has error_log to say about this? Do you have the file perms right?
>>
- --
Cheers
Leemailto:[EMAIL PROTECTED]
$$=qw$808273788400074285838400657879847269820080698276007265677569820727$;
$$=~s$(\d\d)$\$_.=chr(\$1+32)$ge;eval;
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPj1zYqdrfekeF/QBAQEDxgQAoYOSvKGOBHUXgwRcRHdatlAo71tpR4NQ
55fgPbL0e20JiKQ+0X8xbbT6Lixh1ytkIfJZIr3J+7iiIYagkGkrMukFw9IrfMgF
pxu5zY589u1U8BrSzlQIUtMuvmtc40JXZMh5jc/zuasVw0WaeHRVAVsi6wa7qCDE
4MDgvzcuz/g=
=k9JH
-END PGP SIGNATURE-
Re: Possible bug with a 206 Partial Response
not even getting a broken connection. So somehow mod_perl doesn't _really_ think it's an error. Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re: Possible bug with a 206 Partial Response
Hi again, On Mon, 3 Feb 2003, David Dick wrote: > not even getting a broken connection. So somehow mod_perl doesn't > _really_ think it's an error. Check out DEBUGGING in 'perldoc Apache::Registry'. Apache::Registry won't always return what you'd think it should. This has snookered more than one in the past... 73, Ged.
Re: about @INC and handlers directory
Iñaki Martínez wrote: Hi!!! Well this is my firts post in this list... I have a server with several domains which each of them has its own handlers, subroutines and there are several common subrutines. What i want to do it is organize the directory structure, so: /modperl/domain_1/ /modperl/domain_2/ /modperl/domain_3/ /modperl/domain_n/ /modperl/common/ Inside of each one, the handler and subroutines of each domain. The the handlers are: PerlHandler domain_1 ... PerlHandler domain_n to use the common subroutines: common::subroutine_n Now my questions: 1) is this directory structure correct??? 2) can it be improve??? 3) security matters? 4) IMPORTANT: how to set the @INC and where any help, tips, URL are welcome The URL is: http://perl.apache.org/docs/ If you have commons subs, you should be fine as long as they live in the files with declared packages. See: http://perl.apache.org/docs/1.0/guide/porting.html#Script_s_name_space Having a separate @INC for each domain is not possible under mod_perl 1.0 (it does work under 2.0), though there are workarounds which may be inadequate for a heavily loaded server. http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[ANNOUNCE] Apache::PAR 0.10
Version 0.10 of Apache::PAR is now available on CPAN at the following location: http://www.cpan.org/authors/id/N/NB/NBYRD/ This version of Apache::PAR now includes preliminary support for both mod_perl 1.x and 2.x environments natively (without Apache::compat). Note, however, this does not guarantee that any modules, registry scripts, etc packaged with Apache::PAR will work under both 1.x and 2.x - wouldn't that be slick. :-) Also, with this version I have continued to use Apache::test for the module testing framework, so make test does not work "out of the box" under mod_perl 2.x, although it does run with some changes to the generated httpd.conf file (I am hoping to offer a patch for this to the Apache::test author soon). If anyone has any questions or problems (under 1.x or 2.x), please contact me at one of the following: Email: [EMAIL PROTECTED] PAR mailing list: [EMAIL PROTECTED] mod_perl mailing list: [EMAIL PROTECTED] Thanks, -- Nathan Byrd <[EMAIL PROTECTED]>
Re: [ANNOUNCE] Apache::PAR 0.10
Nathan Byrd wrote: Version 0.10 of Apache::PAR is now available on CPAN at the following location: http://www.cpan.org/authors/id/N/NB/NBYRD/ This version of Apache::PAR now includes preliminary support for both mod_perl 1.x and 2.x environments natively (without Apache::compat). Note, however, this does not guarantee that any modules, registry scripts, etc packaged with Apache::PAR will work under both 1.x and 2.x - wouldn't that be slick. :-) Also, with this version I have continued to use Apache::test for the module testing framework, so make test does not work "out of the box" under mod_perl 2.x, although it does run with some changes to the generated httpd.conf file (I am hoping to offer a patch for this to the Apache::test author soon). I doubt that would be useful, because the next release of 1.x (where Apache::test resides) won't happen any time soon, and you can't know what other changes will happen in mp2. Instead, include the whole Apache::Test framework (from mod_perl's cvs!) in the distro, and use it. Once it's released on CPAN, you can simply add it as a prerequisite and remove from the distro. It's also very important for people to start using Apache::Test everywhere, so we can sort out the problems and missing features and release it on CPAN asap. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Apache::PAR 0.10
On Sun, 2003-02-02 at 21:04, Stas Bekman wrote: > Nathan Byrd wrote: > > Version 0.10 of Apache::PAR is now available on CPAN at the following > > location: > > > > http://www.cpan.org/authors/id/N/NB/NBYRD/ > > > > This version of Apache::PAR now includes preliminary support for both > > mod_perl 1.x and 2.x environments natively (without Apache::compat). > > Note, however, this does not guarantee that any modules, registry > > scripts, etc packaged with Apache::PAR will work under both 1.x and 2.x > > - wouldn't that be slick. :-) > > > > Also, with this version I have continued to use Apache::test for the > > module testing framework, so make test does not work "out of the box" > > under mod_perl 2.x, although it does run with some changes to the > > generated httpd.conf file (I am hoping to offer a patch for this to the > > Apache::test author soon). > > I doubt that would be useful, because the next release of 1.x (where > Apache::test resides) won't happen any time soon, and you can't know what > other changes will happen in mp2. Instead, include the whole Apache::Test > framework (from mod_perl's cvs!) in the distro, and use it. Once it's released > on CPAN, you can simply add it as a prerequisite and remove from the distro. > > It's also very important for people to start using Apache::Test everywhere, so > we can sort out the problems and missing features and release it on CPAN asap. > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com That makes since. I was only taking it from the Apache::test direction because it seemed like there might be more involved in separating Apache::Test than Apache::test from mod_perl, and I didn't know there was already plans to release Apache::Test as a standalone module. Thanks for the advice. -- Nathan Byrd <[EMAIL PROTECTED]>
[patch] Changes to RegistryCooker for subclassing
All,
To begin with, should proposed mod_perl patches go to
[EMAIL PROTECTED]? The documentation seemed a little unclear in this
case (I decided to play it safe since I didn't run across any messages
on the dev list from outside developers.)
When I was converting Apache::PAR to work with mod_perl 2.x, one problem
I had was with the way in which ModPerl::RegistryCooker stores member
data. Any subclass of ModPerl::RegistryCooker (in my case, for
Apache::PAR::RegistryCooker) that need to store their own module data
have a problem - they need to pick an array element to store their data
in. Because of the way in which ModPerl::RegistryCooker works
currently, that means hardcoding an array index (because not all array
members are created in new or init). Thus, in
Apache::PAR::RegistryCooker I have a line similar to the following:
use constant PARDATA => 8;
This is not optimal, especially since this has already changed in the
CVS version of RegistryCooker since I started working on it - luckily,
to less members, not more :-)
I propose a change to RegistryCooker.pm so that member data is always
defined in the init sub, so that I could change the above line to
something more like:
use constant PARDATA => -1;
and in my handler, push a new element on after new has been called.
This would keep future changes to the RegistryCooker script from
potentially breaking other modules which must store their own data as
well.
Below is a (small) patch to the CVS version of RegistryCooker.pm to do
this. Down side is that if new member data is added, it would then also
need to be added to the init sub.
If you have any questions, please let me know.
*** RegistryCooker.pm.bak Sun Feb 2 21:00:59 2003
--- RegistryCooker.pm Sun Feb 2 21:10:51 2003
***
*** 107,124
--- 107,128
#
# func: init
# dflt: init
# desc: initializes the data object's fields: REQ FILENAME URI
+ # also declares other members not yet used
# args: $r - Apache::Request object
# rtrn: nothing
#
sub init {
$_[0]->[REQ] = $_[1];
$_[0]->[URI] = $_[1]->uri;
$_[0]->[FILENAME] = $_[1]->filename;
+ $_[0]->[MTIME]= undef;
+ $_[0]->[PACKAGE] = undef;
+ $_[0]->[CODE] = undef;
}
#
# func: handler
# dflt: handler
Thanks,
--
Nathan Byrd <[EMAIL PROTECTED]>
Re: [patch] Changes to RegistryCooker for subclassing
Nathan Byrd wrote:
All,
To begin with, should proposed mod_perl patches go to
[EMAIL PROTECTED]? The documentation seemed a little unclear in this
case (I decided to play it safe since I didn't run across any messages
on the dev list from outside developers.)
[EMAIL PROTECTED] would be the right place. Also help with the doc would be
*very* appreciated, I've started to write the initial doc, but it's a far away
from being useful.
When I was converting Apache::PAR to work with mod_perl 2.x, one problem
I had was with the way in which ModPerl::RegistryCooker stores member
data. Any subclass of ModPerl::RegistryCooker (in my case, for
Apache::PAR::RegistryCooker) that need to store their own module data
have a problem - they need to pick an array element to store their data
in. Because of the way in which ModPerl::RegistryCooker works
currently, that means hardcoding an array index (because not all array
members are created in new or init). Thus, in
Apache::PAR::RegistryCooker I have a line similar to the following:
use constant PARDATA => 8;
This is not optimal, especially since this has already changed in the
CVS version of RegistryCooker since I started working on it - luckily,
to less members, not more :-)
I propose a change to RegistryCooker.pm so that member data is always
defined in the init sub, so that I could change the above line to
something more like:
use constant PARDATA => -1;
and in my handler, push a new element on after new has been called.
This would keep future changes to the RegistryCooker script from
potentially breaking other modules which must store their own data as
well.
Below is a (small) patch to the CVS version of RegistryCooker.pm to do
this. Down side is that if new member data is added, it would then also
need to be added to the init sub.
If you want to extend the object itself, what we can do is to provide a class
method which will return the current size of the object. I suggest a method,
so sub-classes can be further sub-classable.
package A;
use constant SIZE => 5;
sub object_size { SIZE }
package B;
use constant EXTRA_SIZE => 2;
use base qw(A);
sub object_size { SUPER::object_size + EXTRA_SIZE);
package C;
use constant EXTRA_SIZE => 2;
use base qw(B);
sub object_size { SUPER::object_size + EXTRA_SIZE);
etc...
of course here we cast in stone the implementation of the object as an ARRAY,
which is not so cool.
Alternatively we can provide a function to create accessor methods, which will
transparently handle internal changes.
We could also use the 'fields' pragma, but than we get married to the hash
internals, though apparently an optimized compiled time one. We need it
working for 5.6.1+, is it working fine with 5.6.1?
Pseudohashes are certainly out of question.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
