Re: porting from mod_perl1 to mod_perl2

2003-09-06 Thread Philip M. Gollucci
If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 
was added via a path by someone else
2.99 - 3.00 likely this is the cause.

Stas Bekman wrote:

Perrin Harkins wrote:

I am fairly sure it is not perl5.8.


I'm fairly sure it is.  What is your locale set to?  Are you on Red
Hat?  See previous discussions of locale issues on Red Hat 8 and 9 in
the list archives.


Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's 
the client who decides what encoding the data is in, it's either 
CGI.pm  (guessing that what he was using to parse the forms) or more 
low level (io) issues.

Bart, can you test whether you have the same problem when a run the 
same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, 
that will point the blaming finger towards mod_perl 2.0. Someone 
volunteers to add a new test? See

t/modperl/print_utf8.t
t/response/TestModperl/print_utf8.pm
for an example of testing the responding with utf8 data. You can 
probably adopt one of these couples for testing the posting of utf8 data:

t/apache/cgihandler.t
t/response/TestApache/cgihandler.pm
t/modules/cgi.t
t/response/TestModules/cgi.pm
t/modules/cgiupload.t
t/response/TestModules/cgiupload.pm
of course you will want to create a new couple of files for this test.

__
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






--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: apache2, mod_perl: problem with CGI

2003-09-06 Thread Stas Bekman
speeves wrote:
Stas Bekman wrote:

Thanks that did it.


Great.

It would be nice though if the minimum rev level of the CGI.pm could be
mentioned in the doc.
Or maybe it is there somewhere and I skimmed over it.


It's a a CGI.pm problem, really. We can't go and support all possible 
modules that may or may not run under mod_perl 2.0. However we do have 
this section:
http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status 

We probably should specify the version number of each of these 
modules. Can somebody please lookup those modules and send me a patch 
with the version number which starts to support mod_perl 2.0?

No need for Apache::Peek, CGI and CGI::Cookie since I know these 
versions already.

I'm CC'ing Shannon, since he has ported most of the auth modules.


Sorry, I wasn't following the thread, so don't know what the patch is 
for. :(  But, here is a listing of the version numbers for the auth mods 
that are stable, and work with mod_perl2:

Apache-AuthenNIS-0.11
Apache-AuthenNTLM-2.04
Apache-AuthenPasswd-0.12
Apache-AuthenSmb-0.70
Apache-AuthExpire-0.38
Apache-AuthNetLDAP-0.25
Apache-AuthPerLDAP-2.01
Apache-AuthzNetLDAP-0.07
Apache-AuthzNIS-0.11
Apache-AuthzPasswd-0.11
Thanks, speeves

So these are the versions required to run properly with mod_perl 2.0? Here is 
an updated table:

  Module Name Required Dist Package
  -
  Apache::AuthExpire Apache-AuthExpire-0.38
  Apache::AuthNetLDAPApache-AuthNetLDAP-0.25
  Apache::AuthPerLDAPApache-AuthPerLDAP-2.01
  Apache::AuthenNIS  Apache-AuthenNIS-0.11
  Apache::AuthenPasswd   Apache-AuthenPasswd-0.12
  Apache::AuthenSmb  Apache-AuthenSmb-0.70
  Apache::AuthzNIS   Apache-AuthzNIS-0.11
  Apache::AuthzNetLDAP   Apache-AuthzNetLDAP-0.07
  Apache::AuthzPasswdApache-AuthzPasswd-0.11
  Apache::Clean  Apache-Clean-2.00_4 (not released)
  Apache::Peek   Apache-Peek-1.01
  CGICGI.pm-2.93
  CGI::CookieCGI.pm-2.93 (comes in the CGI dist)
I can't see Apache-AuthenNTLM-2.04 being ported yet, though. Here is the list 
of modules that are being in progress of being ported:

  Module Porters
  --
  Apache::MP3Stas Bekman stas AT stason.org
 Clemens Schrimpe csch AT Kiez.NET
  Apache::Scoreboard Stas Bekman stas AT stason.org
  Apache::VMonitor   Stas Bekman stas AT stason.org
  Apache::AuthenNTLM Shannon Eric Peevey speeves AT unt.edu
  Apache::Requesthttp://httpd.apache.org/apreq/
  Apache::Language   Philippe M. Chiasson gozer AT cpan.org
  Apache::AutoIndex  Philippe M. Chiasson gozer AT cpan.org
__
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


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: porting from mod_perl1 to mod_perl2

2003-09-06 Thread Stas Bekman
Philip M. Gollucci wrote:
If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 
was added via a path by someone else
2.99 - 3.00 likely this is the cause.
Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You 
 can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/

__
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


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: apache2, mod_perl: problem with CGI

2003-09-06 Thread Stas Bekman
Philip M. Gollucci wrote:
I'll disagree on this being a windows only problem in CGI. I'll also 
disagree about the version number.

As late as CGI 3.00 this problem exists in Apache 1.3.27 and mod_perl 
1.27 on SunOS.
I believe it's not the problem Bart was talking about. You are most likely 
talking about Apache-request failing, which is how it should be if the 
GlobalRequest option is not set. Bart's problem was finding the request method.

The pdf troubleshooting doc on apache.org site suggest fix (I think its 
5.17) also does _not_ work either

a temp work around I've come up with is

eval {
 $query = CGI-new();
};
return 1 if $@;
instead of just
$query = CGI-new();
You don't need a workaround. You need to setup PerlOptions +GlobalRequest if 
you get this error. Unless you are talking about something else, in which case 
please tell use the exact error you are talking about.

Thanks.

__
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


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: apache2, mod_perl: problem with CGI

2003-09-06 Thread Shannon Eric Peevey
Stas Bekman wrote:

speeves wrote:

Stas Bekman wrote:

Thanks that did it.




Great.

It would be nice though if the minimum rev level of the CGI.pm 
could be
mentioned in the doc.
Or maybe it is there somewhere and I skimmed over it.




It's a a CGI.pm problem, really. We can't go and support all 
possible modules that may or may not run under mod_perl 2.0. However 
we do have this section:
http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status 

We probably should specify the version number of each of these 
modules. Can somebody please lookup those modules and send me a 
patch with the version number which starts to support mod_perl 2.0?

No need for Apache::Peek, CGI and CGI::Cookie since I know these 
versions already.

I'm CC'ing Shannon, since he has ported most of the auth modules.


Sorry, I wasn't following the thread, so don't know what the patch is 
for. :(  But, here is a listing of the version numbers for the auth 
mods that are stable, and work with mod_perl2:

Apache-AuthenNIS-0.11
Apache-AuthenNTLM-2.04
Apache-AuthenPasswd-0.12
Apache-AuthenSmb-0.70
Apache-AuthExpire-0.38
Apache-AuthNetLDAP-0.25
Apache-AuthPerLDAP-2.01
Apache-AuthzNetLDAP-0.07
Apache-AuthzNIS-0.11
Apache-AuthzPasswd-0.11


Thanks, speeves

So these are the versions required to run properly with mod_perl 2.0? 
Here is an updated table:

  Module Name Required Dist Package
  -
  Apache::AuthExpire Apache-AuthExpire-0.38
  Apache::AuthNetLDAPApache-AuthNetLDAP-0.25
  Apache::AuthPerLDAPApache-AuthPerLDAP-2.01
  Apache::AuthenNIS  Apache-AuthenNIS-0.11
  Apache::AuthenPasswd   Apache-AuthenPasswd-0.12
  Apache::AuthenSmb  Apache-AuthenSmb-0.70
  Apache::AuthzNIS   Apache-AuthzNIS-0.11
  Apache::AuthzNetLDAP   Apache-AuthzNetLDAP-0.07
  Apache::AuthzPasswdApache-AuthzPasswd-0.11
  Apache::Clean  Apache-Clean-2.00_4 (not released)
  Apache::Peek   Apache-Peek-1.01
  CGICGI.pm-2.93
  CGI::CookieCGI.pm-2.93 (comes in the CGI dist)
I can't see Apache-AuthenNTLM-2.04 being ported yet, though. Here is 
the list of modules that are being in progress of being ported:
Hi!

Apache-AuthenNTLM-2.04 is indeed ported, I guess I just didn't make a 
formal announcement.   People can download it from the CPAN site under 
my name.

speeves
cws


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


Re: apache2, mod_perl: problem with CGI

2003-09-06 Thread Stas Bekman

So these are the versions required to run properly with mod_perl 2.0? 
Here is an updated table:

  Module Name Required Dist Package
  -
  Apache::AuthExpire Apache-AuthExpire-0.38
  Apache::AuthNetLDAPApache-AuthNetLDAP-0.25
  Apache::AuthPerLDAPApache-AuthPerLDAP-2.01
  Apache::AuthenNIS  Apache-AuthenNIS-0.11
  Apache::AuthenPasswd   Apache-AuthenPasswd-0.12
  Apache::AuthenSmb  Apache-AuthenSmb-0.70
  Apache::AuthzNIS   Apache-AuthzNIS-0.11
  Apache::AuthzNetLDAP   Apache-AuthzNetLDAP-0.07
  Apache::AuthzPasswdApache-AuthzPasswd-0.11
  Apache::Clean  Apache-Clean-2.00_4 (not released)
  Apache::Peek   Apache-Peek-1.01
  CGICGI.pm-2.93
  CGI::CookieCGI.pm-2.93 (comes in the CGI dist)
I can't see Apache-AuthenNTLM-2.04 being ported yet, though. Here is 
the list of modules that are being in progress of being ported:


Hi!

Apache-AuthenNTLM-2.04 is indeed ported, I guess I just didn't make a 
formal announcement.   People can download it from the CPAN site under 
my name.
Thanks Shannon, I have updated the page.

__
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


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html


RE: porting from mod_perl1 to mod_perl2

2003-09-06 Thread Bart Terryn
Stas wrote:

Bart, can you test whether you have the same problem when a run the same
code
under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point
the
blaming finger towards mod_perl 2.0.

Well I did that and guess what? mod_cgi fails as well.
So it is not a mod_perl problem
But for me it is still uncertain who to blame. (cgi.pm? apache2? perl5.8?)

I made a small test for this.
Just in case somebody wants to give it a try
Here is my sample page:
-
html xmlns=http://www.w3.org/1999/xhtml; lang=en
head
meta http-equiv=content-type content=text/html; charset=utf-8 /
/head

body
form method=post action=/mod_perl/utf8-test.pl
enctype=multipart/form-data
textarea name ='utf8-test' cols='60'test: #235; #8212;/textarea
nbsp;nbsp;input type=submit value=publish new content//h4
/form
/body/html
--
Here is the utf8-test.pl:
---
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);

my $q = CGI-new;
my $content = $q-param(utf8-test);
$content .= verify with \x{2014};
my @content = unpack('U*', $content);
$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
print $q-header();
print $q-p($content);
print $q-p('hex');
foreach (@content) {printf %x , $_}
---
and here is the output I get:

test: +entity: 235+ +entity: 151+verify with +entity:8212+

hex

74 65 73 74 3a 20 eb 20 97 76 65 72 69 66 79 20 77 69 74 68 20 2014
--

From which I understand that the original character #8212; is returned as
hex 97 or dec 151.
And would be correct if the characterset would be window-1252 but that is
not what I expected.
Wanted utf-8 to be returned.

If mod_perl is not the correct forum for this (which I agree it isn't) can
somebody point me in the direction of a correct forum? But as said before
the difficulty is that I don't know who to blame

Kind Regards,

Bart



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



RE: porting from mod_perl1 to mod_perl2

2003-09-06 Thread Bart Terryn
I had version CGI 3.00 installed.
Downgraded it to CGI 2.93, put I still have the same result.

The problem as I see it that I have a form with character #8212; in it.
But it is returned as character #151 from the Widows-1252 characterset.
Does everybody agree that it should be returned as #8212; (the utf-8
representation I mean)?

See my previous mail for the test I used.

Bart

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 06, 2003 8:35 AM
To: Philip M. Gollucci
Cc: Perrin Harkins; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: porting from mod_perl1 to mod_perl2


Philip M. Gollucci wrote:
 If you check out the changes to CGI.pm on Licoln Stiens web site, utf8
 was added via a path by someone else
 2.99 - 3.00 likely this is the cause.

Bart, can you try then with an earlier version? e.g. 2.93 was good for me.
You
  can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/

__
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



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Re: $r-headers_out Location and Set-Cookie

2003-09-06 Thread Michael
On Fri, Sep 05, 2003 at 10:13:36, Geoffrey Young said...

 actually, the return value is entirely ignored in Registry scripts - that's 
 why we need the $r-status hack, which is not needed (or desired) in 
 handlers.  if you returned SERVER_ERROR it would still work, so long as you 
 set $r-status :)
 
Oh!  I totally missed that you're using Apache::Registry.  I'm not sure the
best way to do it with that, sorry.

-- 
Michael Stella  | Sr. Unix Engineer / Developer | http://www.thismetalsky.org
All I want out of the Universe is 10 minutes with the source code
and a quick recompile.  - unknown


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Content encoding when filtering proxyed pages

2003-09-06 Thread Esteban Fernandez Stafford


Hello all,

I have a machine acting as a proxy using mod_perl-1.99_09 with apache
2.0.46. This proxy is supposed to filter all html content. So far I
have achieved most of my project's goals. But there is one issue I
can't get straight, this is when the proxy gets a page that is
encoded (like in www.google.com). My first attempt was to DECLINE
filtering such pages, but the $filter-r()-content_encoding() always
gives me 'undef'. Is this something that is not yet implemented or am
I doing something wrong? (See code below) Then I tried looking at
$filter-r()-headers_out()-{'Content-Encoding'} and everything went
just fine!

On the other hand, is it possible that I could put mod_deflate before
my filter to get the content already decompressed for my filter to
parse?

   Thanks a lot in advance

I would like to thank the mod_perl community for mod_perl, it has made
the development of this project fun! And it has kept me from having to
go back to C programming. It was a long time since I last did that.


package WTG::HtmlFilter;

use strict;
use warnings;# FATAL = 'all';

use Apache::RequestRec ();
use Apache::RequestIO ();

use APR::Brigade ();
use APR::Bucket ();

use base qw(Apache::Filter);

use Apache::Const -compile = qw(OK M_POST);
use APR::Const -compile = ':common';

use constant READ_SIZE  = 1024;

use HTML::Parser ();

sub handler : FilterRequestHandler
{
   my $filter = shift;
   my $parser;

   # Initialize parser if not already done
   unless ($parser = $filter-ctx)
   {
  # This is the first call of the filter for a particular request
  # Can we filter this request?
  my $type = $filter-r()-content_type();
  if(! defined $type || $type !~ /^text\/html\b/)
  {
 $filter-remove();
 return Apache::DECLINED;
  }
  # This line gives me undefined
  print STDERR $filter-r()-content_type(), \n;

blah... blah... blah...


   E s  t  eb  a n!


:wq



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Re: CPAN module Apache::Emulator

2003-09-06 Thread Adam Kennedy
For those interested, I've been doing a general clean up of the code
( shrinking the code size down mainly ), prior to starting further 
work on it.

Code available on request.

My intentions is to keep it as light as possible. While Apache::Fake
seems to be able to do a very large amount of things, including 
reading Apache config files by the look of it, I'll be trying to keep
this to some minimum set of features.

Enough to provide all the standard functionality, but not to do any
fancy tricks.
Adam

Nigel Wetters wrote:
David Wheeler [EMAIL PROTECTED] 09/03/03 05:46am 
May I suggest that you post a note to the modperl list announcing 
Apache::Emulator. I think that the folks there might be interested in


your work.


A couple of years ago, I produced a module that emulated a few of the
Apache::Request methods from a CGI environment. The only reason for
doing this was that I was writing an adserver (boo hiss) that I wanted
to run on both Apache and Netscape webservers, but didn't want to write
code in CGI. I released the code to CPAN as Apache::Emulator within a
rarely used Adserver distribution.
My code wasn't complete, or by any means pleasant, but, I guess it was
a good idea because Jorg Walter finished off the job with his excellent,
and comprehensive Apache::Fake distrubution.
Recently, Adam Kennedy has expressed an interest in adding a few
methods to Apache::Emulator, and I dusted off the distribution for him
(separating the code from the Adserver I'd written). I think he would
like to have Apache::Emulator be a slimmed down version of Apache::Fake,
keeping only the most popular features. I'm glad that somepone has taken
an interest.
I think this repackaging is what raised the interest of a few mod_perl
developers. However, at the moment, there is nothing new here. 

Nigel
[EMAIL PROTECTED]


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html