I dunno, but I guess I'll find out, since mine is 1.15. Maybe the
script should check prereq's there, too? I'd been hoping, silly me, to
avoid having to become Yet Another Perl hacker on this level, this
quickly; how do I upgrade that?
Your wishes have been granted, you don't need to become Yet
Hello Angie,
On Fri, 21 Nov 2003, angie ahl wrote:
> >but it's unusual for it not to be there. What's the output of 'httpd -l'?
> >That will tell you if mod_so is in there.
>
> root# /home/httpd/sbin/httpd -l
> Compiled-in modules:
> http_core.c
> mod_env.c
> mod_log_config.c
> mod_mime
Hi there,
On Fri, 21 Nov 2003, Giovani M. Zaffari wrote:
> Someone had a problem with the Reload / Refresh page using the mod_perl?
No.
> I have a script that runs ok only the first time (or when
> it's not in the cache), but the second time some images disappear
> and the browser stay in a loo
Here's the script. I only hide the HTML portions.
I'm using:
Apache/2.0.44 (Unix) mod_perl/1.99_08 Perl/v5.8.0 PHP/4.3.1
--
#!/usr/bin/perl -w
$buffer = $ENV{'QUERY_STRING'};
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($
I've noticed the following with the current cvs build of
mod_perl 2, under Win32 ActivePerl 807 and Apache/2.0.48,
and was wondering if I'm not understanding something. I
first noticed it with Apache::ASP, but the following handler
also illustrates it:
==
On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
As I understand it, they are two different things. The Apache constants
are for telling apache what's going on and
On Fri, Nov 21, 2003 at 11:48:52PM -0800, Stas Bekman wrote:
> > I dunno, but I guess I'll find out, since mine is 1.15. Maybe the
> > script should check prereq's there, too? I'd been hoping, silly me, to
> > avoid having to become Yet Another Perl hacker on this level, this
> > quickly; how do
Jay R. Ashworth wrote:
[...]
I have to become another CVS hacker!
Couldn't I upgrade my test.pm, instead, Daddy? Please? Can't I?
On the opposite, I'm glad you had an old Test.pm, now others who will come
with the stock 5.6.1 won't encounter this problem. We really ought to test the
release wi
On Sat, Nov 22, 2003 at 12:12:37PM -0800, Stas Bekman wrote:
> Jay R. Ashworth wrote:
> [...]
> > I have to become another CVS hacker!
> >
> > Couldn't I upgrade my test.pm, instead, Daddy? Please? Can't I?
>
> On the opposite, I'm glad you had an old Test.pm, now others who will come
> with t
Jay R. Ashworth wrote:
On Sat, Nov 22, 2003 at 12:12:37PM -0800, Stas Bekman wrote:
Jay R. Ashworth wrote:
[...]
I have to become another CVS hacker!
Couldn't I upgrade my test.pm, instead, Daddy? Please? Can't I?
On the opposite, I'm glad you had an old Test.pm, now others who will come
with
On Sat, Nov 22, 2003 at 01:17:21PM -0800, Stas Bekman wrote:
> > Does that mean that, no, I *can't* just upgrade my Test? :-)
>
> Yes, you are doomed and you will have to use that version for the
> rest of your life. If you will be a good netizen, may be in the next
> reincarnation you will be able
Jay R. Ashworth wrote:
Any ideas, BTW, on when 2.0 goes gold?
As soon as it's ready. You can see what's left to be done in
modperl-2.0/todo/release (it's in cvs) or see:
http://cvs.apache.org/viewcvs.cgi/*checkout*/modperl-2.0/todo/release?rev=HEAD&content-type=text/plain
Once this file becomes e
This week at ApacheCon in Las Vegas, Geoff, Philippe and I sat down and
created a new TODO list:
http://cvs.apache.org/viewcvs.cgi/*checkout*/modperl-2.0/todo/release?rev=HEAD&content-type=text/plain
which contains issues we think must be resolved before we release mod_perl 2.0.
Which now makes i
On Sat, 2003-11-22 at 16:46, Stas Bekman wrote:
> This week at ApacheCon in Las Vegas, Geoff, Philippe and I sat down and
> created a new TODO list:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/modperl-2.0/todo/release?rev=HEAD&content-type=text/plain
> which contains issues we think must be res
Perrin Harkins wrote:
On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
Is there something wrong in principle with returning an
explicit status of, eg, 200, rather than using the Apache::*
constants?
As I understand it, they are two different things. The Apache constants
are for telling apache wh
Hi Stas,
On Sat, 22 Nov 2003, Stas Bekman wrote:
> [snip]
> so only when a handler returns OK or DECLINED will the request loop continue
> [snip]
> if you think about it, it makes your life much simpler is you remember
> that all you have to return in OK or DECLINED to continue and anything
> el
16 matches
Mail list logo
