(mere mortals who dislike compiling) so
much easier.
-Original Message-
From: Randy Kobes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 7:00 AM
To: Bart Terryn
Cc: Stas Bekman; [EMAIL PROTECTED]
Subject: RE: porting from mod_perl1 to mod_perl2
On Tue, 9 Sep 2003, Bart Terryn
I think I got your problem solved, you need to:
- print $q-header();
+ print $q-header(text/html; charset=utf-8);
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---
Stas and all of the others,
Stas said:
I think I got your problem solved, you need to:
- print $q-header();
+ print $q-header(text/html; charset=utf-8);
Well actually you did not.
Probably you looked a bit too fast.
(forgivable in view of the numbers of mails you reply to:-)
The utf8-test.pl
Bart Terryn wrote:
Stas and all of the others,
Stas said:
I think I got your problem solved, you need to:
- print $q-header();
+ print $q-header(text/html; charset=utf-8);
Well actually you did not.
Probably you looked a bit too fast.
(forgivable in view of the numbers of mails you reply
Stas,
Sorry to insist.
But here I am again...
Stas wrote:
Actually I haven't looked, I have tested with your code.
Thanks a lot for going through the effort...
Before setting the
header I wasn't getting the unicode chars you put in the form back in the
dump. After setting the header it did
On Tue, 9 Sep 2003, Bart Terryn wrote:
Stas,
Sorry to insist.
But here I am again...
Stas wrote:
Actually I haven't looked, I have tested with your code.
Thanks a lot for going through the effort...
Before setting the header I wasn't getting the unicode
chars you put in the form back
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
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:
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
; (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
Hi,
I have an application running under apache
1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633
I am trying to move this application to apache
2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8
However I run into a problem with character encoding.
Somewhere in this app I put up a form that contains
Hi there,
On Sat, 6 Sep 2003, Bart Terryn wrote:
Hi,
I have an application running under apache
1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633
I am trying to move this application to apache
2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8
However I run into a problem with character
On Fri, 2003-09-05 at 19:14, Bart Terryn wrote:
PS: some might say that this has nothing to do with mod_perl
I would say that, but it's okay, you didn't know.
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
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
On Fri, 2003-09-05 at 21:36, Stas Bekman wrote:
Bart is on win32, AS Perl 5.8.
Oops, sorry Bart, I missed that. Even so, I'm suspicious that 5.8 and
all of its unicode changes are involved somehow.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info:
Apache::porting tries to help you to do the porting to mod_perl 2.0. For more
information please refer to:
http://perl.apache.org/docs/2.0/api/Apache/porting.html
It's a new module and didn't go through much testing. However make sure to
check the known issues, before reporting problems:
http
option would be for you to port Apache::Filter to
run under mp2.
Then your code as well as anyone else's who uses that
module would run
unchanged under mp2. That would be a Good Thing and you'd
be a mod_perl
hero. People on this list would help if you got stuck,
and the
documentation for porting
,
discarding those that aren't needed in mp2 (e.g. Apache::Filter and
FilterChain are definitely to stay in the mp1 world I believe). However there
is a problem with porting modules that include XS code, since the replacement
for Apache::src hasn't been completed yet. Pure perl modules porting should
Since the questions of porting to mp 2.0 are on raise, and there is some
confusion regarding use of Apache::compat. I've done a massive porting docs
update:
Please review the following if you are involved in porting, and let me know if
I've missed something or if something is still unclear
I had some handlers that did not explicitly return OK -- just printed the
coontent and quit. In apache1/mp1 this 'worked' fine.
After migrating to apache2/mp2 these handlers delivered the content to the
browser but then printed a 500 error message to the browser but _not_ to
the error log.
Just
As the docs say $r-send_http_header is deprecated because it is unneeded
in mp2 ... but $r-content_type must be set.
DefaultType is set by default to text/plain in httpd.conf, so browsers
that strictly apply content_type (eg Opera 7) were showing the content as
HTML source.
I had several
Nick Tonkin wrote:
As the docs say $r-send_http_header is deprecated because it is unneeded
in mp2 ... but $r-content_type must be set.
Just a minor nit: $r-send_http_header is *not* deprecated, it's *gone*. Since
yesterday for it's gone for real and is only available only in the back
Hi there,
Sorry there's a lot to digest all at once in your message, but here's
one tip:
On Sat, 29 Jun 2002, Jeff wrote:
- Use 'open my $fh, $filename or die $!; wherever I open files
Use Symbol::gensym if you can, it makes dealing with files much less
accident prone.
73,
Ged.
scripts) I thought it would be a good idea to switch from
CGI to Mod_Perl.
I read all of Stas
Bekman's Porting Guidelines and looked at my scripts.While
Ihave a long programming history, I must admit I started cranking out the
code (ina nice modular fashion) as soon as I grasped the basic
Title: Message
Excuse my typos, I
just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along
with the -w operator(#!/usr/bin/perl -w) and I'm not seeing all the errors
in my logs.
Jeff Crist wrote:
Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use
stricts;' to my code along with the -w operator (#!/usr/bin/perl -w) and
I'm not seeing all the errors in my logs.
Because probably your code was clean in first place. Good for you.
BTW,
PerlWarn On
Jeff wrote:
Hey thanks for the reply. I am making progress but I have run into a
problem where when I have PerlRun enabled my scripts are not see the
field values being passed in the URL. I'm still using cgi-lib.pl not
CGI.pm.
I've never used cgi-lib.pl and you shouldn't either. That
.
Write all my new code so that it will run under Apache::Registry and
then when I have spare time (ya right) go work on porting the older code.
PerlRun works reasonably well, and I have used it to quickly port a
large amount of legacy CGI code that made extensive use of globals.
However
At 05:43 10.06.2002, Mark Korey wrote:
ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
still contains an old value when I try to change it (ie switch to a
different user).
Everything else appears to be working fine.
If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
We found the problem ... this was an odd one (aren't most!?!).
Turns out that the path (i.e. $cgi-cookie(-path ='/', ...); )
was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
Setting that seemed to do the trick.
We are using CGI.pm and did not need to PerlSetupEnv On.
I'm
At 23:55 10.06.2002, Mark Korey wrote:
We found the problem ... this was an odd one (aren't most!?!).
Turns out that the path (i.e. $cgi-cookie(-path ='/', ...); )
was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
Setting that seemed to do the trick.
We are using CGI.pm
Can anyone give me a rough idea how much time it
would take to move a server serving mod_perl websites
from UNIX to OS X?It
usesApache::Session, DBI::Mysql, HTML::Mason,CGI,
andApache::OpenIndex,
among others, and uses both AuthHandlers and AuthzHandlers.
Iknow it's difficult to estimate
On 6/4/02 10:43 AM, Noam Solomon [EMAIL PROTECTED] claimed:
Can anyone give me a rough idea how much time it would take to move a server
serving mod_perl websites
from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and
Apache::OpenIndex,
among others, and uses both
(Apple, you listening?) that they will fix this
gross over-sight.
Cheers,
Ward
-Original Message-From: Noam Solomon
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 04, 2002 10:43
AMTo: [EMAIL PROTECTED]Subject: Porting to OS X
Can anyone give me a rough idea how much time
This is going OT, but the case insensitivity problem is only for the Mac
filesystems. I've that all you need to do is switch the filesystem to ufs
(the bsd version) and the problem is solved. Of course, if you can't switch
fs types I don't know of a workaround. :-)
Drew
At 10:54 AM 6/4/02
On 6/4/02 10:54 AM, Vuillemot, Ward W [EMAIL PROTECTED]
claimed:
I think it is relatively an easy move, IMHO. Just beaware that the Mac OS
filesystem is NOT case-sensitive. Which can cause problems with certain
applications. . .and we hope (Apple, you listening?) that they will fix this
I think it is relatively an easy move, IMHO. Just beaware that the
Mac OS filesystem is NOT case-sensitive. Which can cause problems
with certain applications. . .and we hope (Apple, you listening?) that
they will fix this gross over-sight.
I agree it's a problem, and it's caused me
From: Noam Solomon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Porting to OS X
Date sent:Tue, 4 Jun 2002 13:43:11 -0400
[ Double-click this line for list subscription options ]
Can anyone give me a rough idea how much time it would take to move
At 11:27 AM 6/4/02 -0700, Michael Robinton wrote:
I'd be very interested in how this progresses. I recently helped a
collegue to get a cgi program running under apache using standard perl on
OSX -- I found that the perl distribution that comes with OSX is the
original 5.6 rather than more up to
David == David Wheeler [EMAIL PROTECTED] writes:
I think it is relatively an easy move, IMHO. Just beaware that the Mac OS
filesystem is NOT case-sensitive. Which can cause problems with certain
applications. . .and we hope (Apple, you listening?) that they will fix this
gross over-sight.
Hi,
-- Michael Robinton [EMAIL PROTECTED] wrote:
application, which runs on an aging 486 with 64 megs in our shop and uses
about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and
was very slow. This was on a G4 with 500 megs of memory.
probably it's the same as on FreeBSD:
On Wed, 5 Jun 2002, Alvar Freude wrote:
probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each
restart (apachectl graceful or apachectl restart) it eats all the memory
your mod_perl modules use. Try to build it statically; at least on FreeBSD
it helps, and OSX is FreeBSD
Hello all,
We have an application written in Java using MVC which we would like to port
to mySQL/Perl platform. We have used Struts,to create tags.
Any inputs in this regards will be appreaciated.
Thanks
Manoj
_
Get your FREE
We have an application written in Java using MVC which we would like to
port
to mySQL/Perl platform. We have used Struts,to create tags.
Any inputs in this regards will be appreaciated.
You will probably find that Struts tags can be ported nicely to Template
Toolkit
We have an application written in Java using MVC which we would like to
port
to mySQL/Perl platform. We have used Struts,to create tags.
Any inputs in this regards will be appreaciated.
You will probably find that Struts tags can be ported nicely to Template
Toolkit
Any clues as to your motivation for porting to mod_perl? I've been trying to
sell a mod_perl solution to some Java nuts for some time and any help would be
much appreciated. What really makes mod_perl better than Java? Are there any
performance benchmarks out there that anyone knows about
What really makes mod_perl better than Java?
This is a common thread, which you should look up in the archives. It's
best to avoid starting up a discussion with this vague a question, since it
will lead to a flood of advocacy e-mails.
Didn't the eToys guys do some benchmarking? (Perrin?)
We
Mark Maunder wrote on Mon, Sep 24 2001 (15:44:25 +0100):
Any clues as to your motivation for porting to mod_perl? I've been trying to
sell a mod_perl solution to some Java nuts for some time and any help would be
much appreciated. What really makes mod_perl better than Java? Are there any
John Reid wrote:
We have an application written in Java using MVC which we would like to
port
to mySQL/Perl platform. We have used Struts,to create tags.
Any inputs in this regards will be appreaciated.
You will probably find that Struts tags can be ported nicely to Template
Hi,
I have (happily) compiled and configured Apache with mod_perl, mod_ssl,
mod_php and DSO. Whee!
Now I am working on porting my scripts over...
I have always used strict and perl -w, so for the most part, I think I can
just pop my cgis in the /perl directory as Ive defined it in httpd.conf
: Thursday, July 26, 2001 6:01 PM
To: '[EMAIL PROTECTED]'
Subject: Porting CGI scripts help needed
Hi,
I have (happily) compiled and configured Apache with
mod_perl, mod_ssl,
mod_php and DSO. Whee!
Now I am working on porting my scripts over...
I have always used strict and perl -w
Heres what I did:
I had many scripts in one dir that shared many things; subroutines, global
variables and modules. I wanted to clean things up, so I created a module
called global.pm structured like this:
snip
The custom stuff scripts all end in 1;, and are loaded with my custom
Howdy,
I have an application that's pure mod_perl -- its modules use the request
object to do a few bits of work like reading parameters, query string,
specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff
provided by the methods of Apache, Apache::Util, Apache::URI and
On Fri, Nov 17, 2000 at 11:53:05AM -0800, Bill Moseley wrote:
Now, I'd like to use a few of my modules under CGI -- for an administration
part of the application that's bigger and not used enough to use up space
in the mod_perl server. But it would be nice to have a common code base.
One
Bill Moseley wrote:
Howdy,
I have an application that's pure mod_perl -- its modules use the request
object to do a few bits of work like reading parameters, query string,
specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff
provided by the methods of Apache,
I've posted a simple program that may help you if you're
trying to port windoze javascript-based ASP pages to
Apache::ASP. you can find it here...
http://ruby.ddiworld.com/jreed/web/software/asp2pl.html
jr
--
Joel W.
Joel Reed wrote:
I've posted a simple program that may help you if you're
trying to port windoze javascript-based ASP pages to
Apache::ASP. you can find it here...
http://ruby.ddiworld.com/jreed/web/software/asp2pl.html
I would like to write runtime interpreters for JScript
VBScript -
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI-connect("database","login","password","mysql");
..
$dbh-disconnect;
"James Array" [EMAIL PROTECTED] wrote:
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI-connect("database","login","password","mysql");
..
$dbh-disconnect;
At 08:54 AM 10/20/99 +0200, Stas Bekman wrote:
Besides all the information at perl.apache.org, can you recommend any good
resources (book, web pages) that stand out in your memory as being very
helpful when you were starting out?
I'm not sure why have you discarded the docs at perl.apache.org
At 08:54 AM 10/20/99 +0200, Stas Bekman wrote:
Besides all the information at perl.apache.org, can you recommend any good
resources (book, web pages) that stand out in your memory as being very
helpful when you were starting out?
I'm not sure why have you discarded the docs at
I'm just starting in on porting some scripts over to either
Apache::Registry or Apache::PerlRun, and trying to absorb as much as I can.
It's seems a bit overwhelming at first.
My scripts are reasonably clean, running under -w and use strict, yet I'm
sure I have lots of porting issues to deal
I'm just starting in on porting some scripts over to either
Apache::Registry or Apache::PerlRun, and trying to absorb as much as I can.
It's seems a bit overwhelming at first.
My scripts are reasonably clean, running under -w and use strict, yet I'm
sure I have lots of porting issues
63 matches
Mail list logo
