RE: Documentation patch for mod_perl//win32
Greetings. Stas so if Alessandro or Randy volunteers (please say so), please Stas ask winXX Stas users to send you more winXX specific notes/scenarios and you (the Stas volunteer) will be the official maintainer of the doc and send me the Stas new doc and then the future patches. For 2.0 you will simply have a Stas commit access and be able to maintain these by yourself and go wild. Stas Does this sound good? Randy It does ... I'd be happy to volunteer, or co-volunteer if Randy Alessandro or anybody else wants, to do that for Win32. I sure can co-maintain such a document. The co part is a good idea for several reasons - the most cogent being that I am not a native speaker (I'm italian) and that I spend most of my time working behind a firewall, so I'm not ideally suited for CVS access. And on this note, whenever Stas feels the revision process for this patch is over, I'll send the definitive version... Cheers, alf
[Fwd: Re: Documentation patch for mod_perl//win32]
Alessandro Forghieri wrote: Greetings. Stas so if Alessandro or Randy volunteers (please say so), please Stas ask winXX Stas users to send you more winXX specific notes/scenarios and you (the Stas volunteer) will be the official maintainer of the doc and send me the Stas new doc and then the future patches. For 2.0 you will simply have a Stas commit access and be able to maintain these by yourself and go wild. Stas Does this sound good? Randy It does ... I'd be happy to volunteer, or co-volunteer if Randy Alessandro or anybody else wants, to do that for Win32. I sure can co-maintain such a document. The co part is a good idea for several reasons - the most cogent being that I am not a native speaker (I'm italian) and that I spend most of my time working behind a firewall, so I'm not ideally suited for CVS access. Great! And on this note, whenever Stas feels the revision process for this patch is over, I'll send the definitive version... Then please communicate the patches/doc to Randy. I don't know a thing about winXX, so it's up to you to decide when the initial revision process is done. And even than nothing is cast in stone, I just thought that it would be a good idea to run this through the list while we just start this new document. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Documentation patch for mod_perl//win32
Hi there, On Fri, 23 Nov 2001, Alessandro Forghieri wrote: I sure can co-maintain such a document. The co part is a good idea for several reasons - the most cogent being that I am not a native speaker Heck, you write English better than many Englishmen I know... 73, Ged.
Apache::Registry HEAD request also return document body
Hi all, I have a problem with HTTP head requests and mod_perl. I have been looking at the docs, searching google newsgroup archive but I couldn't find anything thus you are my very last hope ;-) In order to show what the problem is, I have set up two simple identical 'Hello World' type CGI scripts on my machine. One is running under Apache::Registry, the other is running as a plain old CGI. Here is what I get: not_mod_perl test (plain CGI, everything works fine) = [root@frogette /]# lynx --dump http://not_mod_perl Hello World! [root@frogette /]# lynx --dump -head http://not_mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:22:37 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain mod_perl_test (mod_perl, headers are fubar) = [root@frogette /]# lynx --dump http://mod_perl Hello World! [root@frogette /]# lynx --dump --head http://mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:24:50 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain Hello World! PROBLEM HERE A head request should * NOT * return the body of the document Obviously this is very wierd! You can find more details on the config in the attached file. Any ideas on what's going on? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / === Added these two lines in /etc/hosts === 127.0.0.1 mod_perl 127.0.0.1 not_mod_perl This is the test script, test.cgi = #!/usr/bin/perl print Content-Type: text/plain\r\n\r\n; print Hello World!; This is /opt/mod_perl/httpd.conf. It is included in my apache httpd.conf (mod_perl enabled test.cgi) VirtualHost 127.0.0.1 ServerName mod_perl ServerAdmin root@mod_perl CustomLog /opt/mod_perl/www_combined_log combined ErrorLog/opt/mod_perl/www_error_log Alias / /opt/mod_perl/test.cgi Directory /opt/mod_perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On # directives for CGI. These should work everywhere # do not uncomment that bit of text Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none /Directory /VirtualHost This is /opt/not_mod_perl/httpd.conf. It is included in my apache httpd.conf (mod_perl disabled test.cgi) VirtualHost 127.0.0.1 ServerName not_mod_perl ServerAdmin root@not_mod_perl CustomLog /opt/not_mod_perl/www_combined_log combined ErrorLog/opt/not_mod_perl/www_error_log Alias / /opt/not_mod_perl/test.cgi Directory /opt/not_mod_perl # SetHandler perl-script # PerlHandler Apache::Registry # PerlSendHeader On # directives for CGI. These should work everywhere # do not uncomment that bit of text Options ExecCGI AddHandler cgi-script .cgi order allow,deny allow from all AllowOverride none /Directory /VirtualHost Added this in /usr/local/apache/conf/httpd.conf Include /opt/mod_perl/httpd.conf Include /opt/not_mod_perl/httpd.conf Restarted apache not_mod_perl test = [root@frogette /]# lynx --dump http://not_mod_perl Hello World! [root@frogette /]# lynx --dump -head http://not_mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:22:37 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain mod_perl_test = [root@frogette /]# lynx --dump http://mod_perl Hello World! [root@frogette /]# lynx --dump --head http://mod_perl HTTP/1.1 200 OK Date: Fri, 23 Nov 2001 11:24:50 GMT Server: Apache/1.3.19 (Unix) mod_perl/1.25 Connection: close Content-Type: text/plain Hello World! PROBLEM HERE A head request should * NOT * return the body of the document
Re: Apache::Registry HEAD request also return document body
At 11:43 AM 11/23/2001 +, Jean-Michel Hiver wrote: PROBLEM HERE A head request should * NOT * return the body of the document You should check $r-header_only in your handler. http://thingy.kcilink.com/modperlguide/correct_headers/3_1_HEAD.html Bill Moseley mailto:[EMAIL PROTECTED]
RE: [OT] Re: Seeking Legal help
Sorry for continuing the OT thread. I just thought this might be useful... Gunther Birznieks [mailto:[EMAIL PROTECTED]] wrote: By the way, if you are really working for a bank and cashflow is an issue for you in 60 days you can also ask the bank what business banking services they offer. One popular service with small businesses who have large companies working for them is invoice factoring which allows you to sell your invoice (if your company passes a credit check) to the bank for something like 80% of the face value of the account and then when the bank collects the invoice you get the rest minus interest and commissions. Factoring invoices can be a wonderful thing. May I recommend this company: http://www.facteon.com/ You need: (a) to pass a UCC search clean, (b) a credit worthy customer, (c) a contract with your customer, (d) and your customer to agree that the invoice is valid. Then you can get a good chunk of the money up front and more on payment of the invoice by the customer. Your fee depends on how long it takes your customer to pay. If they never pay, you keep the up-front payment and they book it as a loss. It's unlikely that they would grant the same credit with a 1-man company though. And I think they don't like dealing with service businesses. It's usually more for dealing with suppliers with real inventory where the main thing that can go wrong with an invoice is a pricing dispute over a line item of widgets I suspect. From what I know, Factelon works with one man companies and service industries. It's more important that your customer be creditworthy than you, since your customer must agree that the invoice is valid for it to be factored. David
Re: Apache::AuthCookie login faliure reason
I am having some trouble getting Apache::AuthCookie (version 3 which i
believe is the latest version) to do what want:
What i want is:
* To be able to give the user a reson if login fails
- eg reason: * No such username
* Your password was incorrect
Has anyone else come across the same requirement/issue, and how have you
solved it?
I banged my head up against this same wall for awhile until, by reading
AuthCookie's source, I was able to figure out the key to making it all
work. In authen_cred (stripped-down example below), you need to set
a cookie with a value that your ticket-checking code will know is
invalid when you are given invalid credentials.
But, in the interest of security, you don't want to say things like no
such username and incorrect password - that just gives extra
information to someone trying to hack their way in.
sub authen_cred ($$\@) {
my $self = shift;
my $r = shift;
my ($user,$pass) = @_;
if ( check_creds($user,$pass) ) {
# user's credentials are good, so generate ticket, log session, etc
return $user:$ticket;
}
else {
# Modify this (and the code above) if you want more shades of
# meaning here.
return oops;
}
}
Then, in authen_ses_key:
sub authen_ses_key ($$$) {
my $self = shift;
my $r = shift;
my($user,$ticket) = split(/:/,shift,2);
my $retval;
return undef unless $user $ticket;
if ( # ticket is good...
$retval = # something indicating ticket is good...
}
else {
# ticket is bad, so tell the login program/form about it...
$r-subprocess_env('LocalAuthFailure','mumble') if ...;
}
# I also detect an expired session and indicate it like this:
$r-subprocess_env('LocalAuthFailure','expired') unless $retval;
if ( $retval ) {
my $auth_name = $r-auth_name;
# etc...
}
}
After all that, your login program/form just reads LocalAuthFailure
and acts appropriately:
my ($reason,$detail);
if ( $r-prev ) {
$reason = $r-prev-subprocess_env(AuthCookieReason);
$detail = $r-prev-subprocess_env(LocalAuthFailure);
}
#...
# Possibly set an error string:
my $error;
$error = Authentication error. Please try again.
if $reason =~ /bad/;
$error = Your session has expired. Please reauthenticate.
if $reason =~ /bad/ $detail =~ /expire/;
# Now interpolate $error into the HTML we send to the browser
my $form = HERE;
html
head
...
$error
...
I hope that these code snippets are enough to get you started.
...Steve
--
Steve van der Burg
Information Services
London Health Sciences Centre
(519) 685-8300 ext 35559
[EMAIL PROTECTED]
mod perl fails test on my Solaris 2.8 .. ?
Dear All, I've been tasked with setting up a mod_perl apache. I've complied my own perl etc ... in my own home dir, as I need to test our code against it, before passing it off to the addmins for pkg'ing and rolling out to other servers. perl + modules pass all tests. mod_perl appears to build ok, but fails its test (see below for ouput). Appart from that it appears fine (in that it works). I think this is a local solaris (2.8) / my env and not a mod_perl issue, but I am lost as to why this is not working, as I've done this loads of times before on Linux and Solaris - I must be missing something stupid. Enlightenment required! Thanks Greg Cope Intranet Support Group 01304642040 ### mod perl configure: perl Makefile.PL APACHE_SRC=../apache_1.3.22/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/home/copeg/apache-32 ### test ouput cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.22/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...done /home/copeg/test-perl-32/bin/perl t/TEST 0 Can't locate object method new via package URI::URL (perhaps you forgot to load URI::URL?) at ../blib/lib/Apache/test.pm line 252. *** Error code 255 make: Fatal error: Command failed for target `run_tests' # mod perl configure line perl Makefile.PL APACHE_SRC=../apache_1.3.22/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/home/copeg/apache-32 make make test perl -V ouput [14:11:29 copeg@tiger mod_perl-1.26]$ perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos tiger 5.8 generic_108528-10 sun4u sparc sunw,ultra-enterprise ' config_args='-des -Dprefix=/home/copeg/test-perl-32' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-I/usr/local/include' ccversion='WorkShop Compilers 5.0 98/12/15 C 5.0', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib -L/opt/SUNWspro/SC5.0/lib ' libpth=/usr/local/lib /opt/SUNWspro/SC5.0/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib -L/opt/SUNWspro/SC5.0/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at Nov 23 2001 10:23:17 @INC: /home/copeg/test-perl-32/lib/5.6.1/sun4-solaris /home/copeg/test-perl-32/lib/5.6.1 /home/copeg/test-perl-32/lib/site_perl/5.6.1/sun4-solaris /home/copeg/test-perl-32/lib/site_perl/5.6.1 /home/copeg/test-perl-32/lib/site_perl . [14:11:39 copeg@tiger mod_perl-1.26]$ Greg Cope Intranet Support Group 01304642040 PFIZER GLOBAL RESEARCH AND DEVELOPMENT This message and any attachment has been virus checked by the PGRD Sandwich Data Centre.
Re: Apache::Registry HEAD request also return document body
Hi, Thanks for your quick answer, PROBLEM HERE A head request should * NOT * return the body of the document You should check $r-header_only in your handler. http://thingy.kcilink.com/modperlguide/correct_headers/3_1_HEAD.html My only concern is that I thought that Apache::Registry was designed to act as a CGI emulator, allowing not so badly written CGIs to have mod_perl benefits without having to change them. If I have to use the $r object (and therefore the Apache module), then it means that the scripts won't be able to run as standalone CGIs... Am I right? -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::AuthCookie login faliure reason
At 04:09 PM 11/23/2001 +1100, simran wrote: Hi All, I am having some trouble getting Apache::AuthCookie (version 3 which i believe is the latest version) to do what want: What i want is: * To be able to give the user a reson if login fails - eg reason: * No such username * Your password was incorrect Has anyone else come across the same requirement/issue, and how have you solved it? Apache::AuthCookieURL does that. IIRC, it sets a cookie with the failure reason that's returned from authen_cred call. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Apache::Registry HEAD request also return document body
At 02:53 PM 11/23/01 +, Jean-Michel Hiver wrote:
My only concern is that I thought that Apache::Registry was designed
to act as a CGI emulator, allowing not so badly written CGIs to have
mod_perl benefits without having to change them.
Right, sorry I completely missed the Registry part!
Try HEAD on this script.
#!/usr/local/bin/perl -w
use CGI;
my $q = CGI-new;
print $q-header, $q-start_html,
join( BR\n, map { $_ : $ENV{$_} } keys %ENV),
$q-end_html;
If I have to use the $r object (and therefore the Apache module), then
it means that the scripts won't be able to run as standalone CGIs...
Am I right?
Right, maybe that's a good thing ;) (I acutally mix mod_perl code in
applicatins that will run under both.)
Bill Moseley
mailto:[EMAIL PROTECTED]
RE: [OT] Re: How to create a browser popup window
Title: RE: [OT] Re: How to create a browser popup window
Hello,
Thanks for all the window tips.
I have fixed it with out using any javascript.
just mention BASE TARGET=_blank in your html head
and give TARGET=_self to the references which should be opened within the
parent window.
Thanks,
Domien
-Original Message-
From: Rob Bloodgood [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 20, 2001 9:26 PM
To: Nick Tonkin
Cc: mod_perl
Subject: RE: [OT] Re: How to create a browser popup window
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
That is simply not true. window.open() with a named window ('popupwin', in
your example) ALWAYS reuses that window, on every browser I've ever been
able to test. The second call to window.open, with a new URL, simply
refreshes the contents of the popup w/ the new URL. Note, this is *only*
true for named windows. Windows without a window name string as the second
parameter to window.open() will open a new window every time.
It can, however, be a good idea to explicitly call focus() on your child
window, because in the situation I've just mentioned, if the child window's
url is refreshed, it is NOT automatically brought to the foreground.
The original post was wondering how to put mod_perl output in a popup
window. The answer is simply top call window.open() with the URL of the
mod_perl handler as its location.
If one is trying to be responsible about the window(s) being open, adding
a link like
a href="javascript:window.close()CLICK" HERE CLOSE THIS WINDOW/a
in the child window is usually reasonably simple for the user to understand.
Of course, the normal caveats about users understanding something still
apply...
A corrected version of your sample script follows. It's much simpler now...
:-)
SCRIPT LANGUAGE=JavaScript
!-- Hide
var popupwin = null;
function popup(loc,ww,hh) {
var mywidth = (ww + 10);
var myheight = (hh + 10);
var myspecs =
'menubar=1,status=1,resizable=1,location=1,titlebar=1,toolbar=1,
scrollbars=1,width= + mywidth + ,height= + myheight + ';
popupwin = window.open (loc, 'popupwin', myspecs);
popupwin.focus();
}
/SCRIPT
A HREF='javascript:' Look at foo/A
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: Apache::Registry HEAD request also return document body
Try HEAD on this script.
#!/usr/local/bin/perl -w
use CGI;
my $q = CGI-new;
print $q-header, $q-start_html,
join( BR\n, map { $_ : $ENV{$_} } keys %ENV),
$q-end_html;
I'm still getting the headers. I also have this behavior on other boxes
(one on our redhat server and on one of our client's solaris server),
thus I suppose it's not a platform issue.
Here is how it looks on my box:
[root@frogette /]# cat /opt/mod_perl/test.cgi
#!/usr/bin/perl -w
use CGI;
my $q = CGI-new;
print $q-header, $q-start_html,
join( BR\n, map { $_ : $ENV{$_} } keys %ENV),
$q-end_html;
[root@frogette /]#
[root@frogette /]# /usr/local/apache/bin/apachectl restart
/usr/local/apache/bin/apachectl restart: httpd restarted
[root@frogette /]#
And here is what I get:
[root@frogette /]# lynx --head --dump http://mod_perl
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2001 15:14:24 GMT
Server: Apache/1.3.19 (Unix) mod_perl/1.25
Connection: close
Content-Type: text/html
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN
HTMLHEADTITLEUntitled Document/TITLE
/HEADBODYQUERY_STRING : BR
HTTP_ACCEPT_LANGUAGE : enBR
REMOTE_PORT : 34961BR
HTTP_USER_AGENT : Lynx/2.8.4dev.16 libwww-FM/2.14 SSL-MM/1.4.1
OpenSSL/0.9.6BR
HTTP_ACCEPT : text/html, text/plain, audio/mod, image/*, video/*,
video/mpeg, a
pplication/pgp, application/pgp, application/pdf, message/partial,
message/exte
rnal-body, application/postscript, x-be2, application/andrew-inset,
text/richte
xt, text/enriched, x-sun-attachment, audio-file, postscript-file,
default, mail
-file, sun-deskset-message, application/x-metamail-patch,
application/msword, t
ext/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png,
image/x-x
bitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01BR
PERL_SEND_HEADER : OnBR
HTTP_HOST : mod_perlBR
GATEWAY_INTERFACE : CGI-Perl/1.1BR
SCRIPT_NAME : /BR
SERVER_NAME : mod_perlBR
HTTP_ACCEPT_ENCODING : gzip, compressBR
MOD_PERL : mod_perl/1.25BR
SCRIPT_FILENAME : /opt/mod_perl/test.cgiBR
PATH :
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jhiver/bin:/opt/j2sdk1
.3.1/bin:/usr/local/binBR
SERVER_ADDR : 127.0.0.1BR
SERVER_PROTOCOL : HTTP/1.0BR
SERVER_SIGNATURE : ADDRESSApache/1.3.19 Server at mod_perl Port
80/ADDRESS
BR
SERVER_SOFTWARE : Apache/1.3.19 (Unix) mod_perl/1.25BR
SERVER_ADMIN : root@mod_perlBR
REMOTE_ADDR : 127.0.0.1BR
DOCUMENT_ROOT : /usr/local/apache/htdocsBR
REQUEST_URI : /BR
REQUEST_METHOD : HEADBR
SERVER_PORT : 80/BODY/HTML
[root@frogette /]#
Duh... That's a lot of info for a head request :-)
Cheers,
--
== \__ =
/\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB
/ /\__/\ \
_/_/_/\/\_\_ Jean-Michel Hiver - Software Director
\ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968
\ \/__\/
\/\ VISIT HTTP://WWW.MKDOC.COM
== / ===
Re: Apache::Registry HEAD request also return document body
Jean-Michel Hiver wrote: PROBLEM HERE A head request should * NOT * return the body of the document You should check $r-header_only in your handler. http://thingy.kcilink.com/modperlguide/correct_headers/3_1_HEAD.html My only concern is that I thought that Apache::Registry was designed to act as a CGI emulator, allowing not so badly written CGIs to have mod_perl benefits without having to change them. If I have to use the $r object (and therefore the Apache module), then it means that the scripts won't be able to run as standalone CGIs... Am I right? You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. So what you do is you run the registry script as usual but instead of returning the output, you return just the headers. I don't think you can figure out what the headers are going to be without running the whole script (without modifying the script). When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::Registry HEAD request also return document body
You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Thus I guess if I have to amend Apache::Registry it might be worth submitting a pach for a bugfix rather than a subclass of this module wouldn't it? The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. I don't understand you here. It might not give any speed benefits in computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] The option might be 'Off' by default for backwards compatibility. That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? What do you guys think? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
At 03:21 PM 11/23/01 +, Jean-Michel Hiver wrote: Duh... That's a lot of info for a head request :-) Yes, and that's what I get for using HEAD to test! Yesterday's holliday doesn't help todays thinking. How about patching Apache::Registry? Oh, Stas, of course, just posted a better solution. Maybe I'll have better luck repairing my car today. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Apache::Registry HEAD request also return document body
computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. Well, you won't save CPU if you need to compute the whole page anyway... And we're talking of dynamic generated pages, most won't be cached, and those that will might as well send an Expires: header, in which case the proxy and browser will cache the data unless the user forces the cache to be skiped. When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] And another one, Fake or Skip that would just return standard ones, without even bother to run the script... Then the admin will be able to choose the best for it's cause... The option might be 'Off' by default for backwards compatibility. Backward compatibility with a bug? I don't even think there should be a Off setting. Sending the content in a HEAD request is, IMHO, a violation of the HTTP protocol. Also, I think the handler shoulnd't just terminate the script, but send the output until the end of the headers (the first blank line), close the connection, but wait till the scripts ends by it self. Killing it could provoke database corruption or similar problems... That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? Well, we all have been missing it. :( Most probably because when the scripts were only CGI they worked fine, and switching to mod_perl required just a few checks, normally done with a regular browser. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Apache::Registry HEAD request also return document body
On Fri 23-Nov-2001 at 11:45:19PM +0800, Stas Bekman wrote: did you mean to reply to the list? before I reply? Sorry I screwed up because my mailer doesn't know yet that [EMAIL PROTECTED] is a mailing list. I guess it's time to go tweak my muttrc file ;-) So here is a cleaner repost: You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Thus I guess if I have to amend Apache::Registry it might be worth submitting a pach for a bugfix rather than a subclass of this module wouldn't it? The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. I don't understand you here. It might not give any speed benefits in computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] The option might be 'Off' by default for backwards compatibility. That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? What do you guys think? Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
Hi All, Well, you won't save CPU if you need to compute the whole page anyway... And we're talking of dynamic generated pages, most won't be cached, and those that will might as well send an Expires: header, in which case the proxy and browser will cache the data unless the user forces the cache to be skiped. You have a point. It's not so much a big deal for me because I cache things on the server side anyway, but I can see what you mean. The option might be 'Off' by default for backwards compatibility. Backward compatibility with a bug? I don't even think there should be a Off setting. Sending the content in a HEAD request is, IMHO, a violation of the HTTP protocol. It is: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4 cite The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. /cite However some people might have been using the Apache request object to prevent this already. We don't want them to change their code do we? Some other people are unaware of the problem and perfectly happy with it. Fine. Now for all the others (and that includes me :)) it'd be nice to have an option to have the correct behavior. I might just have a look at Registry.pm this week-end and see what kind of horrible hack I can do. Also, I think the handler shoulnd't just terminate the script, but send the output until the end of the headers (the first blank line), close the connection, but wait till the scripts ends by it self. Killing it could provoke database corruption or similar problems... Agreed, in fact it should grab the whole output, or do something with STDOUT when the headers have been printed or something. And another one, Fake or Skip that would just return standard ones, without even bother to run the script... Then the admin will be able to choose the best for it's cause... That would be very bad because the script might return a content type which is something completely different from text/html... unless this is clearly documented as being very bad / dangerous indeed. Okay, so far we might want to have something like: ManageHeadRequests Off|On|Skip It might also be nice to have a 'Fat' option that would put as much info in the head as possible, like language, content-length, link rels, etc (yeah, mozilla supports link rels in the headers, believe it or not :-)) Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
Re: Apache::Registry HEAD request also return document body
Jean-Michel Hiver wrote: You can subclass Apache::RegistryNG to do what you want and send the patch for others to re-use. The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Were your CGI scripts designed to handle HEAD requests? You don't have to alter them to run under mod_perl, do you? Thus I guess if I have to amend Apache::Registry it might be worth submitting a pach for a bugfix rather than a subclass of this module wouldn't it? sure. but it may take a while before there will be a new release. So if you need it now subclassing is the best idea, and submitting the patch for inclusion in the core is for the future release. The idea is interesting but while the implementation is possible it won't give any speed benefit. The positive effect that can be achieved is returning the caller exactly what it has asked for. I don't understand you here. It might not give any speed benefits in computing the headers, sure. But there are number of things that you might want to be in the headers (like date last modified, md5 checksum, content language, content length, etc) and they need the whole page to be computed anyway. that's exactly what I meant. Once you get the whole body computed, you can just discard it if you don't want to send it over the net. You could argue that sending minimalistic headers to speed up head requests is possible, but then you're fucking proxies which are there to save you bandwidth and CPU anyway. I thought that's the reason why you've asked this question and you are supposed to argue this point, not me :) When I think more about it may be if PerlSendHeader is On, we can adjust the code that parses the script's output in search for headers, to return when it finds the 'Content-type' header. Maybe there should be an option, like ManageHeadRequests [On|Off] The option might be 'Off' by default for backwards compatibility. That would do the Right Thing whenever a HEAD request is invoked on the script. I'm quite surprised that this whole issue doesn't seem to have been raised yet - or maybe I missed something? It's not clear what's the right thing for unaltered CGI scripts. Compute the body but send only headers? If the later is the Right Thing, I suppose that this can be done transparently at the Registry level without any new flags. That's why I've suggested that you subclass/patch it :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Apache::Registry HEAD request also return document body
The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Were your CGI scripts designed to handle HEAD requests? You don't have to alter them to run under mod_perl, do you? You didn't have to design them to because apache handles it for you. With mod_perl/apache/registry, that doesn't work anymore. If ::Registry et al are going to be touted as drop in solutions for your existing perl cgi stuff, then IMO they have to handle this by default, or they aren't doing what I, and probably a lot of other people, would expect them to. hopefully someone will care enough to patch it. adam
Class data preloading modules
Hi,
I have some modules that use the idiom
package Foo;
use Bar;
{
my $bar = Bar-new(args);
sub bar { return $bar }
}
which works fine until one tries to preload them in startup.pl.
I realized that, by preloading, I was innocently sharing the same DBI
object between Apache children (nothing strange happened during
testing, but I guess it was only a question of time stress).
I also happen to have Foo subclasses that need the DBI connection to
produce otherwise shareable (read only) class data.
My question is about good programming practice in this case. I guess
I have three options:
(init once per MaxRequestsPerChild)
* initialize the class data externally, from within a method.
* do something like
{
my $bar;
sub bar {
$bar = BAR-new(args) unless $bar; # too ugly? performance loss small?
return $bar;
}
}
(init only once)
* initialize everything in the parent Apache, just make sure to create
new DBI connections in the children.
What do you think?
Thanks,
--
Adriano
Re: Apache::Registry HEAD request also return document body
Adam Prime wrote: The perldoc Apache::Registry says Apache::Registry - Run unaltered CGI scrips under mod_perl Were your CGI scripts designed to handle HEAD requests? You don't have to alter them to run under mod_perl, do you? You didn't have to design them to because apache handles it for you. Sorry, I didn't run mod_cgi for years, I didn't know it properly handles HEAD requests. With mod_perl/apache/registry, that doesn't work anymore. If ::Registry et al are going to be touted as drop in solutions for your existing perl cgi stuff, then IMO they have to handle this by default, or they aren't doing what I, and probably a lot of other people, would expect them to. hopefully someone will care enough to patch it. As I said to Jean-Michel nobody has complained in the last 3 or so years :) Jean-Michel has promised to send the patch ;-) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::AuthCookie login faliure reason
Bill Moseley wrote:
At 04:09 PM 11/23/2001 +1100, simran wrote:
Hi All,
I am having some trouble getting Apache::AuthCookie (version 3 which i
believe is the latest version) to do what want:
What i want is:
* To be able to give the user a reson if login fails
- eg reason: * No such username
* Your password was incorrect
Has anyone else come across the same requirement/issue, and how have you
solved it?
Apache::AuthCookieURL does that. IIRC, it sets a cookie with the failure
reason that's returned from authen_cred call.
in the code line 154 is this:
$r-subprocess_env('AuthCookieReason', 'bad_cookie');
and on 157 this:
$r-subprocess_env('AuthCookieReason', 'no_cookie');
im not sure why your having problems on setting this
the examples in the cpan tarball on the login.pl page are like this
#!/usr/bin/perl
use strict;
my $r = Apache-request;
$r-status(200);
my $uri = $r-prev-uri;
my $reason = $r-prev-subprocess_env(AuthCookieReason);
then in his html code it says:
PFailure reason: '$reason'. Please enter your login and password to
authenticate./P
which shows up if its a 'bad cookie' or 'no cookie'
basically the authentication failed
one thing to mention in the prev not prev subprocess
is that you set it as subprocess_env and then call it with prev later
