Re: porting from mod_perl1 to mod_perl2
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 --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Help wanted with locations / configuration
Marc Slagle wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] You might want to look at having a translation handler. As in a PerlTransHandler, yes? We're doing something similar to this, where images and javascripts live under the same directory structure as the handler is managing. Instead of trying to configure this via that httpd.conf file, we chose to have a translation handler look at the incoming uri and determine whether the request is for a static file or for the code. Is there a performance penalty with this? You're using Perl code to inspect the URI, and then handing control back to the Apache core if it is a static file. I wanted to avoid requests for static files wasting time by going to a Perl handler only to be returned to the Apache core to serve the file, hence my LocationMatch override that catches requests for static files. Thanks for the code snippet, though - it looks pretty good to me aside from that concern. - Steve
Re: Help wanted with locations / configuration
Perrin Harkins wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, They have, indeed. Thanks, everyone! but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: [snip] Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. - Steve
Re: Help wanted with locations / configuration
petersm wrote: Steve Hay [EMAIL PROTECTED] wrote Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch Correct me if I'm wrong, but can't you just say Location /myproject Location /myproject AddHandler perl-script .cgi PerlHandler MyProject-dispatcher /Location using AddHandler instead of SetHandler. This will not override the default handler for things like images/stylesheets/static html. This way you don't need the LocationMatch ^/myproject/(images|javascript|stylesheets) ... tags. I prefer for reasons that I can't really explain to have the Perl handler locations having no extension - e.g. things like /myproject/component1 rather than /myproject/component1.cgi. I can't see how to achieve that with an AddHandler. (And even if I did get that working somehow, then the Perl handler would have to hand control back to the Apache core when it receives a request for /myproject/images.) Thanks for the idea, though. If I manage to overcome my inexplicable aversion to file extensions then it certainly looks like the simplest solution. - Steve
Re: Help wanted with locations / configuration
On Tuesday 09 September 2003 11:16, Steve Hay wrote: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. I have achieved that using the configuration Perrin suggested. The prefix (/myproject) is a parameter of the configuration of the application called apache_location_root, and the config script fills a mod_perl.conf.tt2 like this: Alias [% apache_location_root %]/views [% prj_root %]/www/htdocs/views Alias [% apache_location_root %]/images [% prj_root %]/www/htdocs/images Alias [% apache_location_root %]/scripts [% prj_root %]/www/htdocs/scripts Alias [% apache_location_root %]/styles [% prj_root %]/www/htdocs/styles Location [% apache_location_root %] # Nothing to do with the filesystem, just handlers available in @INC. /Location In our case the motivation for that is that we don't know whether our application will run in its own Apache server, so you can hard-code that stuff, or will need to be added to an already functioning Apache. -- fxn
Re: Help wanted with locations / configuration
Hi!
On Tue, Sep 09, 2003 at 10:05:43AM +0100, Steve Hay wrote:
Location /myproject/css
SetHandler default
/Location
Location /myproject/img
SetHandler default
/Location
This is working as expected, i.e. request for /css/foo.css or /img/bar.png
are not handled by Apache::Dispatch
What about requests for /css or /img ? Are they handled by
Apache::Dispatch? The problem I found with my LocationMatch override is
that requests for files were caught, but requests for directories
slipped through to the Perl handler.
Unfourtunatly, request for /css are handled by Apache::Dispatch. At least it
seems so, but I'm enterly sure if it's the actual request that's beeing
served, or an internal redirect (or some other funky Apache internal thing,
like ErrorDocument or index generation)
It does seem like a feature/problem of Apache. I tried various config
options (and modifications to Apache::Dispatch), but no matter what I did,
request for /img/ allways get passed to PerHandler instead of default
handler
Request for anything inside /img/ work as expected.
No, wait a minute...
If I request /foo/bar/ (another dir) than it doesn't work either.
I still do not know if this a bug in
Apache / mod_perl / Apache::Dispatch / YourHandler, and/or internal redirect.
Or if this is expected behaviour.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Portability Question
On Mon, 2003-09-08 at 23:29, Philip M. Gollucci wrote: I haven't really had a hard time with this except: CGI.pm ($query = CGI-new()) What about it? Is it not working? Spreadsheet::WriteExcel (0.26 or less for Win2k/ISS5.0PerlEx current is .40 most likely not thread safe) GD.pm (ActiveState only has GD1.x for 5.6.1 and compile errors for GD2.x on 5.8.0) XML::Simple (Active State5.6.1 is only at 1.06 missing some critical features from the current ~2.05) DateTime modules (datetime.perl.org ActiveState 5.6.1 has nothing... I think 5.8.0 might have some) Building your own .ppm files seems like the only way to solve these. use lib qw(...) (ISS automagically adds . to this. Under unix, this is not the case First thought, use FindBin, but its not thread safe, so mod_perl2.x fails. Only anwser I've come up with is to have an installation script edit a place holder in the main file You could use a config file or an environment variable, but what is the problem with FindBin exactly? I haven't heard about it not being thread safe before. However, caching is much more beneficially in IIS5.0/PerlEx then apache1.x/mod_perl1.x (rarely if ever get server by the same child in Apache) In apache 1.x on Win32, you always get the same child since there is only one. With 1.x on FreeBSD, the allocation will basically round-robin through all of your live apache children. - Perrin
Re: Help wanted with locations / configuration
Steve Hay [EMAIL PROTECTED] wrote Thanks for the idea, though. If I manage to overcome my inexplicable aversion to file extensions then it certainly looks like the simplest solution. I understand the argument that it's better for the user to not know the extension of the file they are running but, if it really bothers you then you could do something like Location /myproject AddHandler perl-script .steve /Location and then put a '.steve' extension onto your scripts and that way it's a little more personalized... :) Michael Peters Venzia
Re: Help wanted with locations / configuration
On Tue, 2003-09-09 at 05:00, Steve Hay wrote: As in a PerlTransHandler, yes? Yup. Is there a performance penalty with this? You're using Perl code to inspect the URI, and then handing control back to the Apache core if it is a static file. I wanted to avoid requests for static files wasting time by going to a Perl handler only to be returned to the Apache core to serve the file, hence my LocationMatch override that catches requests for static files. Static File: Devel::Timer Report -- Total time: 0.0006 secs Interval TimePercent -- 00 - 01 0.0003 48.49% INIT - Entering translation handler 01 - 02 0.0002 36.91% Entering translation handler - Checking to see if we are asking for a static file 02 - 03 0.0001 14.60% Checking to see if we are asking for a static file - This is a request for a static file, telling apache where it is Request we want to pass on to our handler: Devel::Timer Report -- Total time: 0.0005 secs Interval TimePercent -- 01 - 02 0.0002 40.90% Entering translation handler - Checking to see if we are asking for a static file 00 - 01 0.0001 31.48% INIT - Entering translation handler 02 - 03 0.0001 27.62% Checking to see if we are asking for a static file - This is not a request for a static file, returning DENIED We decided to do it this way because we are also doing some other things in the translation handler that I didn't pass along in the snippet. Since we were already putting a translation handler in place to do our trickery there, it seemed to make the most sense to us to add the code to handle static requests there. By no means am I suggesting that this is the best way, but we're pretty happy with it. Marc Slagle
problem with RPM instalation of Apache and Mod_perl on RedHat and Mason
I have RedHat 9, I have installed Apache using rpmwich comes with RedHat9 (httpd-2.0.40-21) then ihaveinstalled mod_perl using rpm mod_perl-1.99_07-5then is have installed the latest Mason filesHTML-Mason-1.22) but when i try to start Apache it saysApache/Constants.pm not found. I serched CAPAN forApache::Constents it points to mod_perl which ihave already installed. for your information i have added these lines tohttpd.conf:PerlModule HTML::Mason::ApacheHandlerFilesMatch "\.html$"SetHandler perl-scriptPerlHandler HTML::Mason::ApacheHandler/FilesMatchthe error i get is:
Can't locate Apache/Constants.pm in @INC (@INCcontains/usr/lib/perl5/5.8.0 .) at/usr/lib/perl5/site_perl/HTML/Mason/ApacheHandler.pmline 13.!BEGIN failed--compilation aborted at/usr/lib/perl5/site_perl/HTML/Mason/ApacheHandler.pmline 13.!Compilation failed in require at (eval 1)line 3.![Tue Sep 09 16:28:02 2003] [error] Can't load Perlmodule HTML::Mason::ApacheHandler for server127.0.0.1:0, exiting...!
To over come this problem i put in these entries
:I put in these lines in my httpd.conf file
PerlModule Apache2 PerlModule Apache::compat PerlModule HTML::Mason::ApacheHandlerFilesMatch "\.mml$" SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler/FilesMatch
now the server satrts up well but when i wanted totest some Mason set up i put in a file called"greet.nml" in my document root its contesnt :Greetings, % ("Earthlings", "Martians")[rand 2] %
only one line but is get internal server error when ilook it up in the browserIt would help if some would let me know what to do and what is happning
It would be of great help if some one could tell me the step by step process for installing apache, mod_perl, and mason in a clean and eassy way and what version numbers to use sothat i dont face much problems is RedHat 8 or 7 better than RedHat9 when it comes to this
it will also help if you could provide me some links also
thanks in advance
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Portability Question
On Mon, 8 Sep 2003, Philip M. Gollucci wrote: Say I want the same code to work under: Win2k/ISS5.0CGI Win2k/IIS5.0PerlEX Win2k/Apache1mod_perl1 Win2k/Apache2mod_perl2 FreeBSD/Linux/Sun/Apache1mod_perl1 FreeBSD/Linux/Sun/Apache2mod_perl2 FreeBSD/Linux/Sun/Apache1,2CGI Assume perl 5.6.1 ActiveState on Win2k and perl 5.8.0 on Unix environments. Assume CGI.pm = 2.98 I haven't really had a hard time with this except: [ ... ] GD.pm (ActiveState only has GD1.x for 5.6.1 and compile errors for GD2.x on 5.8.0) XML::Simple (Active State5.6.1 is only at 1.06 missing some critical features from the current ~2.05) [ ... ] Text::Aspell ... egad... One of my co-workers has compiled this for 5.6.1 ActiveState on Win2k/WinXP Pro using MSCV++ 6.0 if anyone is interested since ActiveState has nothing. We have the above three packages in our 5.8 repository at http://theoryx5.uwinnipeg.ca/ppms/. -- best regards, randy kobes
Re: Help: Can't coerce GLOB to string...
[Forwarded from [EMAIL PROTECTED] [EMAIL PROTECTED]]
Hello,
In response to :
Kurt George Gjerde wrote:
BTW: I've fixed my can't coerce GLOB to string problem I had last
week.
Was unrelated to mod_perl (sorry). It seems XML::LibXSLT produced some
errors which went straight to STDERR. Under CGI these ends up in the
error_log but under mod_perl it seems STDERR is just a black hole (?).
Would it be possible to map STDERR to log_error()?
Unless I'm missing something, mod_perl doesn't do anything special with
STDERR
(it does tie STDIN and STDOUT for 'perl-script' handlers). Apache opens
stderr
to error_log, and then everything just works. e.g. if you do:
warn Foo;
or
print STDERR OOOPS\n;
this ends up in error_log, no?
I suppose that XML::LibXSLT redefines STDERR then. Try to see what it
does to
create this problem.
The key to this problem is that the function $parser-parse_string()
cannot take a scalar as argument.
This way it works and doesn't produce Can't coerce ... anymore :
my $sheet = $parser-parse_string('EOT');
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:output method=text indent=no/
xsl:strip-space elements=FILTER_RULE NAT_RULE LOG_RULE/
!-- this XSLT sheet transforms a netfilter XML rule document into an
iptables script --
xsl:template match=NETFILTER
...
EOT
Best regards
Jean Philippe GUILLEMIN
http://shweps.free.fr
[EMAIL PROTECTED]
RE: porting from mod_perl1 to mod_perl2
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 code is reading what comes out of the form (which has a
charset=utf-8 meta tag, so that is OK, see my previous mail)
The utf8-test.pl then replaces the characters higher the 7F with char. ref
entities but with the string '+entity: ' in front of the value(see below
lines 11 and 12 of utf8-test.pl).
And to double verify the information read back from the form is also
unpacked from unicode values into their hex counterparts.
And then both strings are printed out as normal low ascii characters (7f),
so no need to set the utf-8 flag here.
From further testing I have seen that only unicode characters that actually
have a representation in the win1252 characters set come back under their
corresponding win1252 characterset position.
So the form would for example contain an ndash character (unicode position
dec 8211 or U+2013) .
But that is read back as character dec 150 or hex 96.
And if the form contains a right single quotation (unicode position dec 8217
or U+2019), it comes back under its win1252 position of dec 146 or hex 92.
I would have expected if I send something in under its unicode position, it
would come back to me under its unicode position.
But then again I may be wrong.
And the utf8 flag in the header only means that is will be utf8 encoded and
should not be confused with the characterset used.
I am under the impression I confusing myself more and more here.
So if somebody has been on this path before and knows the truth, let him
speak up!
(Oh did I mention already that I have tested only against IE6, because the
browser could be the cause as well of this odd(?) behaviour.)
Thanks all for your patience.
I would really like to get to the bottom of this.
Bart
Here is utf8-test.pl, again this time with line numbers
1:#!/perl/bin/perl.exe
2:use strict;
3:use CGI;
4:use CGI::Carp qw(fatalsToBrowser);
5:
6:my $q = CGI-new;
7:my $content = $q-param(utf8-test);
8:$content .= verify with \x{2014};
9:my @content = unpack('U*', $content);
10:$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
11:$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
12:print $q-header();
13:print $q-p($content);
14:print $q-p('hex');
15:foreach (@content) {printf %x , $_}
and here is the htlm form that triggers the utf8-test.pl:
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
and here is the result this all produces:
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
Re: CPAN module Apache::Emulator
Adam Kennedy wrote: Interesting idea, and I'm fine with it, although I dislike ApacheEmu. Despite being longer, surely it would fit somewhere like Emulate::Apache::XX. That's fine too. I just thought of a namespace starting with ApacheXXX:: so it'll be placed next to Apache:: in the global list of modules... __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: porting from mod_perl1 to mod_perl2
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 to:-) Actually I haven't looked, I have tested with your code. 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 print out exacly the same unicode character. I didn't have a chance to mess with the hex representations yet. [...] (Oh did I mention already that I have tested only against IE6, because the browser could be the cause as well of this odd(?) behaviour.) I think this is where the weak point is. You need to compare characters on the server side, not trying to rely on the browser, which as you have seen will render them improperly if you didn't set the right header. You have two things happening: read input, send output. The problem can be in any of the two and worse, it can be in both and the error can fix itself when doubled. You need to verify first that the input is read properly, then the same for the output. I have started writing the test for mp2 to verify utf8 input, hopefully I'll finish it soon. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problem with RPM instalation of Apache and Mod_perl on RedHat and Mason
parvez mohamed wrote: I have RedHat 9, I have installed Apache using rpm wich comes with RedHat9 (httpd-2.0.40-21) then i haveinstalled mod_perl using rpm mod_perl-1.99_07-5 I don't know what version HTML::Mason is relying on (I'll let the mason developers to comment on it), but you probably want to use the latest released mod_perl 1.99_09 and apache 2.0.47 before you start reporting problems which were fixed alredy. You can find rawhide rpm versions of those on rpmfind.net. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: porting from mod_perl1 to mod_perl2
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 print out exacly the same unicode
character.
Well that is strange. I just changed my code and still am getting the endash
back as code 150 and not as the 8212 code (the way it went in).
Are you sure that you have the 2 lines in the test program that change the
multibyte utf-8 encoded characters into their values?
(the famous lines 11 and 12)
Because if not, then I can understand that you have to put the changed
header in as you would be sending utf-8 encoded data to the client.
And it would also explain why you would 'see' the same character after
putting the utf-8 header in.
I didn't have a chance to mess with the hex representations yet.
That makes me wonder even more about the thing above.
[...]
I think this is where the weak point is. You need to compare characters on
the
server side, not trying to rely on the browser, which as you have seen will
render them improperly if you didn't set the right header.
Again that is the purpose of the dreaded lines 11 and 12 of my test program.
I don't want to render the character, I just want to display the actual
(utf-8 encoded) code that I read back from the form.
You have two things happening: read input, send output. The problem can be
in
any of the two and worse, it can be in both and the error can fix itself
when
doubled. You need to verify first that the input is read properly, then the
same for the output.
Believe me.
I also ran tests that write out the data to disk and then used a hex dump of
that file to actually verify what is in there. I got the same results. But
that go a bit tedious hence my little test program that does more or less
the same thing.
For your convenience here is the test program again
You will note that I change the $q-header print statement, but as said
before the outcome is still wrong.
Could you confirm that you indeed used this script unmodified and still are
recieving correct output?
As said the important part is in line 11 and 12.
You will need perl 5.8 in order to make those 2 lines work properly
(5.6 does not understand unicode correctly)
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
use CGI::Cookie;
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(text/html; charset=utf-8);
print $q-p($content);
print $q-p('hex');
foreach (@content) {printf %x , $_}
I have started writing the test for mp2 to verify utf8 input, hopefully
I'll
finish it soon.
Thanks a lot for your support...
Bart
Mod Perl 1 Install Apache 1
I am trying to make mod perl one and keep getting the following error. Paul perl Makefile.PL APACHE_SRC=../apache_1.3.28/src APACHE_PREFIX=/srv/www DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Make r.o): In function `Perl_reentrant_retry': reentr.o(.text+0x67b): undefined reference to `gethostent_r' reentr.o(.text+0x83e): undefined reference to `getgrent_r' reentr.o(.text+0xa39): undefined reference to `getnetent_r' reentr.o(.text+0xbfe): undefined reference to `getpwent_r' reentr.o(.text+0xdca): undefined reference to `getprotoent_r' reentr.o(.text+0xfa2): undefined reference to `getservent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_ghostent': pp_sys.o(.text+0x9db6): undefined reference to `gethostent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_gnetent': pp_sys.o(.text+0xa1e6): undefined reference to `getnetent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_gprotoent': pp_sys.o(.text+0xa574): undefined reference to `getprotoent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_gservent': pp_sys.o(.text+0xa970): undefined reference to `getservent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_gpwent': pp_sys.o(.text+0xad2d): undefined reference to `getpwent_r' /usr/local/ActivePerl-5.8/lib/5.8.0/i686-linux-thread-multi/CORE/libperl .a(pp_sys.o): In function `Perl_pp_ggrent': pp_sys.o(.text+0xb1ee): undefined reference to `getgrent_r' collect2: ld returned 1 exit status make[3]: *** [target_static] Error 1 make[3]: Leaving directory `/home/apache/src/apache_1.3.28/src' make[2]: *** [build-std] Error 2 make[2]: Leaving directory `/home/apache/src/apache_1.3.28' make[1]: *** [build] Error 2 make[1]: Leaving directory `/home/apache/src/apache_1.3.28' make: *** [apaci_httpd] Error 2
Re: Sending a different protocol header
--- Geoffrey Young [EMAIL PROTECTED] wrote: btw, can you please explain what ICY is for me? I believe ICY is a protocol used for streaming media, so these headers are probably an extension of HTTP that can be used instead of the pure ICY protocol. That's a guess, anyway. :-) Chris = Become a better Web developer with the HTTP Developer's Handbook http://httphandbook.org/
RE: porting from mod_perl1 to mod_perl2
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 in the dump. After setting the header it did print out exacly the same unicode character. Well that is strange. I just changed my code and still am getting the endash back as code 150 and not as the 8212 code (the way it went in). If you're using ppm to install mod_perl, could you try the latest version at http://theoryx5.uwinnipeg.ca/ppms/? There were some changes made recently that may affect the above problem. Note that the version in the mod_perl.ppd hasn't changed, so you may have to uninstall mod_perl and then install it to force ppm to upgrade. -- best regards, randy kobes
