Re: document contains no data errors (with mod_ssl)
Hi there, On Mon, 30 Sep 2002, Anthony E. wrote: am receiving document contains no data error messages quite frequently. [snip] incidentally, i noticed i am getting a lot of these errors in the error_log: Out of memory! Callback called exit. If you run out of memory then your Apache will probably fail to send properly the page you want to send, hence the messages from your browser and in the error_log. It sounds to me like you need to read the mod_perl Guide, particularly the bits about memory... Please see the mod_perl home page for a link to the Guide. 73, Ged.
bug with IO::Scalar IO::String Text::Iconv and XML
Hi
here is a program that shows something wrong when using
Text::Iconv with
IO::Scalar or IO::String
read a sample xml file, with an accented character, after
xml parsing (which translates to utf-8), translate back to iso-
8859-1.
also prepare a simple utf-8 string with text::iconv
problem :
when print is done with IO::Scalar or IO::String redirection,
conversion fails.
pascal
here the XML is read with XML::Simple or XML::LibXML,
but this is the same with XML::XPath
note Text::Iconv-raise_error(1) raises no error.
source program test:
use warnings;
use XML::Simple;
use Text::Iconv;
use XML::LibXML ;
Text::Iconv::-raise_error(1);
my $string=q{?xml version=1.0 encoding=iso-8859-1 ?
grpétude/grp};
my $string2=Text::Iconv-new(iso-8859-1,utf-8)-convert
(étude);
my $doc =XML::LibXML-new-parse_string($string) ;
my $ref=XML::Simple-new-XMLin($string);
my $C= Text::Iconv-new('UTF-8','ISO-8859-1');
print \n--\n;
print $doc-toString, \n raw:, $ref,\tconv:, $C-convert
($ref);
print \n str2:, $string2,\tconv:, $C-convert($string2);
--
source program calltest
-
use IO::Scalar;
use IO::String;
my $page;
my $CACHE =new IO::Scalar \$page ;
select $CACHE;
do 'test' ;
select STDOUT;
print $page ;
my $io=IO::String-new(my $tocache);
select $io ;
do 'test' ;
select STDOUT ;
print $tocache ;
do 'test' ;
---
output of PERL test
--
--
?xml version=1.0 encoding=iso-8859-1?
grpétude/grp
raw:étude conv:étude
str2:étudeconv:étude
raw print is UTF-8, conv print is iso
XML output is in iso directly
Iconv conversion is successful
raw and str2 are the same
all correct
now look at other output :
==
output of PERL calltest
IO::Scalar --
?xml version=1.0 encoding=iso-8859-1?
grpétude/grp
raw:étude conv:étude
str2:étude conv:étude
IO::String--
?xml version=1.0 encoding=iso-8859-1?
grpétude/grp
raw:étude conv:étude
str2:étude conv:étude
STDOUT--
?xml version=1.0 encoding=iso-8859-1?
grpétude/grp
raw:étude conv:étude
str2:étudeconv:étude
=
ICONV fails to convert when IO redirection,
looks like characters are not the same between raw and
string2, which
both should be utf-8 translation of étude
the toString method of LIbXML seems to output back in iso-8859-
1, without explicit
translation, but this fails with IO redirection too.
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)
Daft question - preventing the username password box from appearing.
All, How do I change the behaviour of get_basic_auth_passwd() I do not wish to have the prompt box appear, I want to have a dynamically produced login form which when submitted carries out the users previous command (I have an authentication system which 'times out' a user) the problem I have is that this doesn't work:- my $response=timedout($r); #returns a string of html to display $r-custom_response(AUTH_REQUIRED,$response); return AUTH_REQUIRED; The problem is this still prompts the user for his username and password, and only displays the html is the user presses cancel. How do I ditch the login box completely? Regards Marty
Re: Daft question - preventing the username password box from appearing.
Martin Moss wrote: All, How do I change the behaviour of get_basic_auth_passwd() I do not wish to have the prompt box appear, I want to have a dynamically produced login form which when submitted carries out the users previous command (I have an authentication system which 'times out' a user) the problem I have is that this doesn't work:- my $response=timedout($r); #returns a string of html to display $r-custom_response(AUTH_REQUIRED,$response); return AUTH_REQUIRED; The problem is this still prompts the user for his username and password, and only displays the html is the user presses cancel. How do I ditch the login box completely? use FORBIDDEN instead of AUTH_REQUIRED. see recipe 13.7 in the Cookbook, or Apache::AuthCookie for examples of how this is done (hint, it requires a bit of fancy footwork :) HTH --Geoff
Re: Daft question - preventing the username password box from appearing.
On Tuesday, 2002-10-01 at 14:16:47 +0100, Martin Moss wrote: I do not wish to have the prompt box appear, I want to have a dynamically produced login form which when submitted carries out the users previous command (I have an authentication system which 'times out' a user) You can't in mod_perl. When you use Basic Authentication, the *browser* pops up the prompt box. To change this, you have to ditch Basic Auth and implement something else. You best start by looking at the various auth packages in Apache and those in in Perl (Apache::.*Auth). Then consider doing this in Javascript or in HTML. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
Re: Daft question - preventing the username password box from appearing.
thanks to everyone, Geoff's post made me re-examine AuthCookie and I realised I wasn't supposed to use the get_basic_auth_pw method at all. Thanks I understand whats going on now. Cheers Marty - Original Message - From: Lupe Christoph [EMAIL PROTECTED] To: Martin Moss [EMAIL PROTECTED] Cc: modperl [EMAIL PROTECTED] Sent: Tuesday, October 01, 2002 3:06 PM Subject: Re: Daft question - preventing the username password box from appearing. On Tuesday, 2002-10-01 at 14:16:47 +0100, Martin Moss wrote: I do not wish to have the prompt box appear, I want to have a dynamically produced login form which when submitted carries out the users previous command (I have an authentication system which 'times out' a user) You can't in mod_perl. When you use Basic Authentication, the *browser* pops up the prompt box. To change this, you have to ditch Basic Auth and implement something else. You best start by looking at the various auth packages in Apache and those in in Perl (Apache::.*Auth). Then consider doing this in Javascript or in HTML. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
cookies and IE
Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
IE.
I'm setting a cookie and then doing a redirect as follows:
my $c = Apache::Cookie-new( $r,
-name = 'userdata',
-value = $cookie,
-expires = '1d',
-path = '/dealers'
);
$r-content_type('text/html');
$c-bake;
$r-header_out(Refresh=0;url=/dealers$request_uri);
$r-no_cache(1);
$r-send_http_header;
$r-print( print_refresh_page_content() );
(print_refresh_page_content() just returns a string of authenticated)
After the authenticated message is printed it should refresh back to the
/dealers/ URL, except this time the handler will see there is a cookie
and print out the real data, not a username/pass prompt.
This works *perfectly* in mozilla linux, galeon, mozilla windows, and
ie6 under windows XP. It *doesn't* work on ie 6 under win98, winME, or
ie 5.5 run through crossover office. It displays the authenticated
page, but then refreshes back to the login page. No cookie is set, but
debug when setting the cookie shows the following:
Set-Cookie=userdata=[data]; path=/dealers; expires=1d at
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Refresh=0;url=/dealers/ at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Pragma=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Cache-control=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Connection=close at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Content-Type=text/html at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Expires=Tue, 01 Oct 2002 18:30:31 GMT at
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
This is the same that is printed out when a working browser gets cookies
set.
I've played around with the security settings, and even at the lowest
setting, with IE set to prompt for any cookies, it won't even
acknowledge that I'm trying to set a cookie.
Anyone have any ideas/solutions/thoughts?
--
Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net
I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
subprocess_env wont change variable set with PerlSetEnv
I have a variable that is set with PerlSetEnv in
my Apache config.
PerlSetEnv SOMEVAR FOO
On some occasions my PerlTransHandler
changes this variable:
$r-subprocess_env('SOMEVAR','BAR');
This used to work fine, and my PerlHandler (HTML::Embperl)
would see $ENV{SOMEVAR}=='BAR'
However, I have just upgraded to apache 1.3.26,
mod_perl 1.27 and added mod_ssl 2.8.10, and this
behaviour no longer works.
$r-subprocess_env('SOMEVAR','BAR');
*only* works if SOMEVAR has not previously been
defined in the server config. Otherwise it remains
unchanged.
Any ideas as to what is happening??
Many thanks,
Chris Allen.
Re: cookies and IE
On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote:
Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
IE.
I'm setting a cookie and then doing a redirect as follows:
my $c = Apache::Cookie-new( $r,
-name = 'userdata',
-value = $cookie,
-expires = '1d',
-path = '/dealers'
);
$r-content_type('text/html');
$c-bake;
$r-header_out(Refresh=0;url=/dealers$request_uri);
$r-no_cache(1);
$r-send_http_header;
$r-print( print_refresh_page_content() );
Turns out the issue was the 'expires' tag... IE wouldn't set the cookie
until it was set to '+1d'
alan
--
Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net
I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
At 11:30 AM -0700 10/1/02, Alan wrote: Hi folks... I'm having a bit of a weird problem with Apache::Cookie and IE. I'm setting a cookie and then doing a redirect as follows: This must come up once every few months. I'd complain about that fact, but the irony is that just last week I couldn't figure out why a new site I was working on wasn't setting cookies in IE and I'd done the same thing I'd read about a dozen times. IE doesn't reliably set cookies on a refresh. I believe the only solution is to rearchitect the site. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Makefile 'PERL=' definition.. 1.99_07, and previous releases
In the Makefile that gets generated there are some PERL= and
FULLPERL=statements that get set to whichever perl you ran on the
originalMakefile.PL file. For example I ran /usr/bin/perl-5.8.0-threaded on
it, andthey got set properly. The problem is theres an additional 'MakeMaker
macrosection' down lower in the Makefile that gets generated that just seems
toalways default to /usr/local/bin/perl, instead of any custom one that
isspecified when running the original perl on Makefile.PL.I just
thought I'd point this out and ask if this was intentional or anoversight. I
manually changed it and was able to finish doing a 'makeinstall', which was
previously hanging up on the 'pure_install' sectionbecause it invoked the
wrong perl executable.So that takes care of the problem I posted about a
week ago ;) Now off tofinish testing this version of
mod_perl.so..--# --- MakeMaker macro section:MODPERL_MAKEFILE =
Makefile.modperl#PERL = /usr/local/bin/perlPERL =
/usr/bin/perl-5.8.0-threadedAPACHE_PREFIX =MOD_INSTALL = $(PERL)
-I$(INST_LIB) -I$(PERL_LIB) -MModPerl::MM \-e "ModPerl::MM::install({@ARGV},'$(VERBINST)',0,'$(UNINST)');"
error from my .htaccess file
Hello,
I know very little about Apache or mod_perl and I'm really lost.
I am running Apache 1.3.22 and mod_perl 1.21 on a Sun Solaris 2.6 machine. I'm sure
Apache and mod_perl are running as I can successfully grab that out of
$ENV{SERVER_SOFTWARE}. I'm using perl 5.005_03.
I am trying use a .htaccess file to allow NT Authenitcation on a directory.
However, I am getting a server error
Syntax error on line 6 of /web/content/askLucent/password-reset/.htaccess:
Invalid command 'PerlAuthenHandler', perhaps mis-spelled or defined by a
module not included in the server configuration
Here are the contents of my .htaccess file
Limit GET POST
AuthName NT Domain\Login and Password
AuthType Basic
#PerlSetVar NT_Controllers 'na02il0015dc00:na02il0015dc01'
PerlSetVar NT_Controllers 'na02il0015dc04:na02il0015dc01:NA02IL0015DC02'
PerlAuthenHandler Apache::AuthenN2
require valid-user
/Limit
I found the following thread from this list:
http://www.mail-archive.com/modperl@apache.org/msg29191.html
and I did rebuild using perl Makefile.PL EVERYTHING=1 which I confirmed did modify
Apache, however, I still get the exact same error.
Does anyone have an idea of what else I should be looking for?
Thanks.
Jennifer
mod_perl 1.27 core dumping on all requests
mod_perl 1.27, apache 1.3.26, Solaris 2.8/Sparc, Perl 5.6, gcc 2.95.2 My problem, I get a consistent core dump in perl_handler(), mod_perl.c:842 on a standard (non-perl script) request in my server as specced above. I've debugged it to where I know what's happening, but have no clue why it's doing so. I make a simple request. I do a telnet, then: GET / HTTP/1.0[ret][ret] and the server processes the request. For some reason it goes though perl_handler()/mod_perl, my understanding was it wouldn't even go though perl_handler() unless I configured a directory with SetHandler. Anyways, it executes the macros that start that function, and dies on the dPPDIR macro (from mod_perl.h). That macro tries to get the perl per_directory_config based on the request_req per_dir_config. The problem is, the request doesn't have any r-per_dir_config, so it's NULL, and tries to dereference NULL, and, well, you know what happens. This has happened with various configurations. The weird thing is that it happens at the doc root directory, which has the default per-dir config from httpd.conf. Anyone with any ideas? Richard Homolka Technical Architecture Citadel Investment Group L.L.C. Phone: 312-384-2982 Cell: 312-952-8762 E-Mail: [EMAIL PROTECTED]
Perl environment variables in mod_perl 1.26
Gday fellow mod_perl'ers, In order to get mod_perl to look in the right place for my perl modules, I have been using the SetEnv PERL5LIB /foo method in my apache config file. This is giving me bad results when I use more than one mod_perl module. To my knowledge, the way this works is that when the perl interpreter is loaded, it prepends the normal INC paths with the directory[s] in your PERL5LIB environment variable. What I'm finding is that when the first mod_perl module loads, it uses the PERL5LIB variable to build up an INC list. Then when the second mod_perl module is called, it's not rebuilding the INC path. Say I have an apache config like so: Directory /foo SetEnv PERL5LIB /tmp/foo /Directory Directory /bar SetEnv PERL5LIB /tmp/bar /Directory If I load a mod_perl module from the /foo directory, then the INC for perl contains /tmp/foo. If that mod_perl script then does an internal redirect to another mod_perl module in /bar, then the INC path is not rebuilt with the new environment. This is relevant for PerlAuthzHandler's and such, as they are loaded by apache first, as mod_perl modules. Then once authenticated, they do some sort of internal redirect to the original request. If this original request was for a mod_perl module, then it doesn't recieve it's appropriate INC. The environment variables are all set properly, ie: PERL5LIB is what is supposed to be, it's just that the INC hasn't be rebuilt. Does anyone know if this is a bug in mod_perl? I have found a way around it by just manually pushing the environment variable onto the INC before the second mod_perl module is called. But I believe this is an incorrect way of doing things. cheers Danial Pearce
