Bill Marrs wrote:
Please report to the list the bug id so we can document this issue for
those who have the same problem with older httpds. Thanks.
OK, I've posted it.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259
Thanks for the fix!
For the archives: This bug has been fixed
Try this patch:
[...]
Feel free to submit this bug report and the fix to httpd-dev. Please let
me know if you do that, so I won't duplicate it. But I'd prefer that you
do it so you can make sure that it gets fixed in the next release, since
you need it working.
I've just verified that your
Please report to the list the bug id so we can document this issue for
those who have the same problem with older httpds. Thanks.
OK, I've posted it.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259
Thanks for the fix!
-bill
Bill Marrs wrote:
Try this patch:
[...]
Feel free to submit this bug report and the fix to httpd-dev. Please
let me know if you do that, so I won't duplicate it. But I'd prefer
that you do it so you can make sure that it gets fixed in the next
release, since you need it working.
I've just
, this is a bug in mod_deflate. You don't
see it in mod_cgi, because mod_cgi doesn't really handle buffering and
flushing, since it just reads the data from the pipe to the process.
mod_deflate didn't follow the deflate() spec, saying that the caller shouldn't
call deflate, when there is no data
I've been kicking around a proxy server here and found your
Apache-ProxyRewrite most useful but I have this quirk perhaps you can help
with.
I'm using version 0.17. I've read in the ChangeLog that one of the more
recent fixes (v0.16) may have been to address the problem I'm encountering.
I can measure it myself if you can provide me with URLs to your resources
and identify them in terms of which one is mod_CGI and which is mod_perl.
This is the mod_cgi one that works fine, no errors:
http://shevek.kenyonhill.com/cgi/test.pl
This is the mod_perl one (same script) that generates
-
From: Bill Marrs [EMAIL PROTECTED]
To: Slava Bizyayev [EMAIL PROTECTED]; Stas Bekman
[EMAIL PROTECTED]; Philippe M. Chiasson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, July 21, 2003 6:49 AM
Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string
not specified)
I can
and check its size when flushing...
I may not be understanding the output you sent or what you're saying, but I
still don't follow why this would be a mod_deflate bug if mod_cgi with the
same script has no problem.
Well, the problem is that I get this error in my error_log:
[Mon Jul 21 14:18:55 2003] [error] 4297: ModPerl::RegistryBB: 20014:Error
string not specified yet at /var/www/perl/test.pl line 6.
Also, more important, the script seems to be terminating and/or any output
following the 'print '
Marrs [EMAIL PROTECTED]
To: Slava Bizyayev [EMAIL PROTECTED]; Stas Bekman
[EMAIL PROTECTED]; Philippe M. Chiasson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, July 20, 2003 6:22 PM
Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string
not specified)
At 11:07 AM 7/19/2003
Randy Kobes wrote:
[..]
Just to verify, I also get this with ActivePerl 806,
Apache/2.0.47, and the current mod_perl cvs version.
Here's some partial debug information:
PERL58! 28083490()
PERL58! 280648b5()
and what are these two perl
: [EMAIL PROTECTED]
Sent: Saturday, July 19, 2003 7:01 AM
Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string
not specified)
At 07:16 PM 7/18/2003, Slava Bizyayev wrote:
In my understanding _it is_ a problem of mod_deflate.
The error does not occur if I run the same test
-8-- Start Bug Report 8--
1. Problem Description:
# Problem: When I add PerlOptions +Parent I get a segfault.
#
# Breaks with:
# Windows 2000 SP2
# Apache 2.0.46
# ActiveState Perl 5.8.0 (build 804)
# mod_perl 1.99.10dev
On Fri, 18 Jul 2003, Marc M. Adkins wrote:
-8-- Start Bug Report 8--
1. Problem Description:
# Problem: When I add PerlOptions +Parent I get a segfault.
#
# Breaks with:
# Windows 2000 SP2
# Apache 2.0.46
# ActiveState Perl
Philippe M. Chiasson wrote:
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:
This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
-1, this is a wrong solution. print ; should flush just like it did in
mod_perl
Issac Goldstand wrote:
Right. Could you possibly clarify the difference between SetHandler
perl-script and SetHandler modperl? I'm still not sure I've got the
straight of it yet...
You must be kidding ;) Have you read the sections at the URL posted below?
Stas Bekman wrote:
Sreeji K Das
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Issac Goldstand [EMAIL PROTECTED]
Issac Goldstand wrote:
Looking at it now, I tend to agree... I just have a vague recollection
of
my first mod_perl 2 handler (Written only 2 weeks ago, though I dabbled
with
the C API
Issac Goldstand wrote:
[...]
(Starting
with mor_perl 2)... I'm toying with the idea of starting the porting
tutorial, but I want to make sure it's written well for clueless people
(which I probably still at least half count as :-)) and with accurate
content.
porting or starting? We already have
At 04:24 AM 7/15/2003, Stas Bekman wrote:
Philippe M. Chiasson wrote:
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:
This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
-1, this is a wrong solution. print
Bill Marrs wrote:
At 04:24 AM 7/15/2003, Stas Bekman wrote:
Philippe M. Chiasson wrote:
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:
This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
-1
#addoutputfilterbytype
Ah, I misunderstood the mod_deflate docs. I think at the time, it didn't
seem to work with just one of them in-place, so I added the
other. *SHRUG* I can't say I'm a pro at Apache config files, I just
tinker until it works. I assume this is irrelevant to the bug, though.
I'm
Right. Could you possibly clarify the difference between SetHandler
perl-script and SetHandler modperl? I'm still not sure I've got the
straight of it yet...
Issac
Stas Bekman wrote:
Sreeji K Das wrote:
[...]
You need to use 'SetHandler perl-script' for that, see:
Following demonstrates the problem:
$ cat /tmp/test.conf
Perl
@Include = /tmp/test1.conf;
/Perl
Listen 43499
$ cat /tmp/test1.conf
Perl
$Port = 42480;
/Perl
$ httpd -X -f /tmp/test.conf
Syntax error on line 7 of /tmp/test.conf:
Use of uninitialized value in subroutine entry at
) and that's another reason why nobody answered.
3 - Even if it was on topic, you're testing with *very* old service packs.
If you, absolutely, must use an old service pack, then please tell us why;
The question is, maybe it's not a bug on the NTLM2 module - but a bug on
Windows NT itself
Looks like PerlSetEnv's are not propagated as
expected.
I've pasted my original mail to the list. However,
after going through the code, it looks like
scfg-PassEnv is not synced with Perl's %ENV
structure.
Following is a simpler example:
$ cat /tmp/test.conf
Perl
;
/Perl
PerlPassEnv MY_TEST_VAR
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:
This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
One thing that could help is if someone could take the time to write a
test for this bug.
Gozer out.
At 10
When I use Apache 2.0.46, mod_deflate with mod_perl-1.99_09 (or the latest
mod_perl-2.0 CVS), perl buffering is off ($|=1), and my perl script prints
nothing (e.g. 'print ;'), I get the following error:
[Wed Jul 02 10:10:00 2003] [error] 19513: ModPerl::RegistryBB: 20014:Error
string not
Seems to be a problem with calling IoFLUSH() on an already flushed
handle.
This patch seems to fix it for me.
Index: xs/Apache/RequestIO/Apache__RequestIO.h
===
RCS file:
This fixed the bug for me.
At 10:48 AM 7/2/2003, you wrote:
#define mpxs_output_flush(r, rcfg) \
/* if ($|) */ \
-if (IoFLUSH(PL_defoutgv)) { \
+if (bytes 0 IoFLUSH(PL_defoutgv)) { \
MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg-wbucket, TRUE)); \
}
Hi Stas and guys -
As of Sat May 31 08:38:30 UTC 2003
1) I have the following installed and tested:
Server Version: Apache/2.0.46 (Unix)
mod_perl/1.99_10-dev (CVS)
Perl/v5.8.0
mod_ssl/2.0.46
OpenSSL/0.9.7b
2) Everything is looking good!
3) GOOD JOB FOLKS...
Aloha = Beau;
http://perl.apache.org/maillist/email-etiquette.html
Posting to the list is just sending a message to the
address which you will be given after you subscribe.
The above should either be updated, or the welcome message should be
updated. I've just subscribed to the digest version, and the
Stas wrote:
Matthew, can you please repost it to the mod_perl list?
There are many more people who can followup on this.
Thanks.
I won't be subscribed long enough to read any replies to this mesg, but
am posting here at Stas' suggestion. Hopefully someone here will be able
to update the docs
repeat this MaxThreads-times, Apache does not respond any more.
But:
- When I run the Perl-Script as CGI with Perl 5.8 it works fine.
- And also if I run ActivePerl-5.6.1.635 it works fine with mod_perl.
It seems to be a Bug in either mod_perl or Perl itself,
(Or a forgotton Workaround on a Windows-Bug
--- Original Message ---
From: Stas Bekman [EMAIL PROTECTED]
To: Ron Savage [EMAIL PROTECTED]
Cc:
Sent: Sat, 01 Mar 2003 12:47:39 +1100
Subject: Re: [MP2] Apache::Reload date bug
Ron Savage wrote:
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
Hi Stas
Output when run as /perl/main.cgi
On Wed, 26 Feb 2003 22:30:51 -0600 (CST), Randy Kobes wrote:
On Thu, 27 Feb 2003, Ron Savage wrote:
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
HI Randy
The mod_perl 2 ppm package (for ActivePerl 8xx) at
http://theoryx5.uwinnipeg.ca/ppms/ is updated
periodically with a cvs build - as
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
Hi Stas
Have you tried the current mod_perl cvs?
No. Being usually a Windows (shudder) user, I wait for Randy to issue
a build.
Today I spent 4 hours failing to install Red Hat 6, Red Hat 8 and
Mandrake 9 on a brand new Dell with a
On Thu, 27 Feb 2003, Ron Savage wrote:
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
Hi Stas
Have you tried the current mod_perl cvs?
No. Being usually a Windows (shudder) user, I wait for Randy to issue
a build.
The mod_perl 2 ppm package (for ActivePerl 8xx) at
Ron Savage wrote:
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
And what your error_log says?
Nothing is output to the error_log.
Have you tried the current mod_perl cvs?
__
Stas BekmanJAm_pH -- Just
in the server
error log.
--
--
Apache/2.0.43 Server at 127.0.0.1 Port 80
-8-
The part of httpd.conf controlling /perl/. Note Dummy is not included
here, but the original module, which revealed the original bug, is:
8
Ron Savage wrote:
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-8-
#!/usr/bin/perl
use strict;
use warnings;
use
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
And what your error_log says?
Nothing is output to the error_log.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 25/02/2003
http://savage.net.au/index.html
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn(foo\n)'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backupperl -le warn(qq|foo\n|)
foo
C:\Backupperl -le 'warn(foo\n)'
well, you've got the idea, right.
Perhaps someone on win32
On Wed, 19 Feb 2003, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn(foo\n)'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backupperl -le warn(qq|foo\n|)
foo
C:\Backupperl -le 'warn(foo\n)'
Randy Kobes wrote:
On Wed, 19 Feb 2003, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn(foo\n)'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backupperl -le warn(qq|foo\n|)
foo
C:\Backupperl -le 'warn(foo\n)'
Folks
I don't know if this an Apache problem, or a mod_perl problem.
Apache::Reload outputs a UTC date rather than a local date, when it
encounters an error. Here's an excerpt from my log.
Notice how the dates go Sun, Mon, ..., Sun.
[Sun Feb 16 18:31:25 2003] [error] [client 127.0.0.1]
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Just for the record, in case it helps someone, I'm getting weird
failures, unpredictably -- there's not one thing that seems to set
it off: sometimes they happen, sometimes they don't.
[Thu Feb 13 10:12:28 2003] [notice] Parent: child process exited
The only thing that puzzles me about this thread is that it seems to be
leaning towards the position that says;
If the developer just does straight out weird stuff and messes with
$r-status in a cgi-script and expects it to work with Apache::Registry
(which as far as I understand is a cgi
received a bug report, where the
script wasn't doing the right thing.
I can't remember whether you modeled Cooker after PerlRun or RegistryNG.
the current logic in RegistryNG represents a recent change and is my fault
http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2
this approach we immediately received a bug report, where
the script wasn't doing the right thing.
I can't remember whether you modeled Cooker after PerlRun or RegistryNG.
the current logic in RegistryNG represents a recent change and is my fault
http://marc.theaimsgroup.com/?l=apache-modperl-devm
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the
execution status is Apache::OK return that new status.
. That's the
approach that is taken by Apache::Registry and it seems that most people are
happy with it. PerlRun does return the execution status, but when I first made
the Cooker use this approach we immediately received a bug report, where the
script wasn't doing the right thing
if
it was changed by the script. That's the approach that is taken by
Apache::Registry and it seems that most people are happy with it.
PerlRun does return the execution status, but when I first made the
Cooker use this approach we immediately received a bug report, where
the script wasn't doing
David Dick wrote:
[...]
The only thing that messed me up was when running a script with mod_cgi,
you can return your own status codes and apache will happily go along
with it. However, when you run the same script under mod_perl's
Apache::Registry, you suddenly get Apache::Registry second
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's,
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
[snip]
More information about this error may be available
in the server error log.P
[snip]
Anyone got any ideas?
What does it say in the error_log?
73,
Ged.
Good Point. Forgot to mention that the error log is completely empty. :)
Ged Haywood wrote:
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
[snip]
More information about this error may be
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Forgot to mention that the error log is completely empty. :)
Are you getting core dumps?
73,
Ged.
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Ged Haywood wrote:
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
Forgot to mention that the error log is completely empty. :)
Are you getting core dumps?
73,
Ged.
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than
G'day all,
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
HISTORY:
I've been using MD5 digests of the html sent from my scripts as ETags,
hence saving an important bit of bandwidth. Got a little bit carried
away with the success of this project and
as address: 0xabababab, as you have
traced it. So it
could be a bug in the ActiveState's perl or is it a standard
one?
it is perl 58 cpan source I have rebuilt all myself debug
but the bug also happens with asperl 58
here is more precicion, I have followed the trace starting
[EMAIL PROTECTED] wrote:
Hi !
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux
and it works
just fine.
I tested it with libxml2-2.4.23 and XML::LibXML 1.52
and it still segfaults.
I can't reproduce
Hi
here is a revised complete report bug
Hi
on
SERVER_SOFTWARE: Apache/2.0.44 (Win32) mod_perl/1.99_08-dev
Perl/v5.8.0
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
everything rebuild debug
test code
---
use
[EMAIL PROTECTED] wrote:
Hi
here is a revised complete report bug
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works
just fine.
[...]
output ok but apache segfault
---
here
of the internal redirect.
I tried to make a bare bones config that duplicated the problem, but my
really simple config worked just fine. Does this bug ring any bells?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
without a package name (just $r)
because of the internal redirect.
I tried to make a bare bones config that duplicated the problem, but my
really simple config worked just fine. Does this bug ring any bells?
Aha! I just found this in the archives (which I looked at before posting
Hello,
We began to encounter some odd segfaults, and after poking through
mod_perl believed that we have found the problem. The DESTROY() function
in Table.xs is not honoring the read only flag in self, which would seem
to be a bug.
For reasons we are still trying to discover (;), it's being
With ColdFusion you can call the same page eg the line_main2.cfm can be
called from the line_main2.cfm with different parameters. Unfortunately
the client PC does not seem to pass the NTLM/Basic Authorization Header
the second time the page is called.
Maybe this is handled via a subrequest.
[...]
Basically we are losing data sent to a mod_perl program. We request the
page page.fxml?name=aladress=swedenproblem=huge. When our program
receives this request it will only be page.fxml without any of the
arguments sent.
[...]
I haven't followed the original thread, so I apologize if I
Ian Stuart wrote:
Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1
I believe that the install process does not test for the presence (or
lack of..) of the apache_server_root/modules directory.
This causes a problem during the mod_perl installation as the
pseudo-command cp
I know I shouldn't, but I have a URI that goes:
a_silly_clients_filename 2 . jpg
And when I try:
$r-log_error ( $r-uri );
the result is:
[Fri Nov 08 09:59:37 2002] [error] a_silly_clients_filename 2.jpg
Is this real, or is it me?
Thanks,
lee
Lee Goddard
I believe that there is a bug in the Apache::AuthenNTLM module.
Configuration:
I have an Apache server with ColdFusion MX 6 installed, there is a
requirement for NTLM authentication with the server.
I implemented the PerlAuthenHandler Apache::AuthenNTLM to solve this
problem.
Problem
Hi there,
On 8 Nov 2002, Brett Hales wrote:
I believe that there is a bug in the Apache::AuthenNTLM module.
Did you see this?
73,
Ged.
--
Date: Thu, 7 Nov 2002 17:46:15 -0600 (CST)
From: Gerald Combs [EMAIL PROTECTED
Hi - I am wondering if there is a bug in AuthCookieDBI.pm?
There is function group which is called to verify the user's group when there is a
Require group directive. It starts like this:
sub group($$\)
{
my( $self, $r, groups ) = _;
When more than one group is specified
Hello.
I have posted a note here before, and want to thank those that took time
to try to solve this strange problem, but unfortunately none of the
suggestions have helped us so far, except for helping us ruling out things
that could have been incorrect.
Now I have received some more information
Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1
I believe that the install process does not test for the presence (or
lack of..) of the apache_server_root/modules directory.
This causes a problem during the mod_perl installation as the
pseudo-command cp $SOURCE/mod_perl.so
I have recently seen a number of stuck processes on an
Apache server I run. The problem is associated with events
which appear to be attacks by the Slapper worm. The
server's OpenSSL has been upgraded, so actual penetration
by Slapper does not occur. However the stuck processes
are inconvenient,
module.
SNIP
Recently we switched from using the standard Apache request-object to
using the Apache::Request one, for the added functionality, but this has
not had any effect at all as far as we can tell, and the bug keeps
happening...
I ran into a problem that the param parts of a request
not had any effect at all as far as we can tell, and the bug keeps
happening...
I ran into a problem that the param parts of a request were flushed
when read for the first time... so if you lose them (don't store them)
then you cannot access them again.
Yep, noticed this myself when re
, but this doesn't completely solve the problem
either.
We have encountered the bug on several versions of both apache and
mod_perl, on different os's:
Solaris/mod_perl 1.25/apache 1.3.19
Debian/mod_perl 1.26/apache 1.3.23
We have also seen it both in the compiled versions and in the standard
the standard Apache request-object to
using the Apache::Request one, for the added functionality, but this has
not had any effect at all as far as we can tell, and the bug keeps
happening...
I ran into a problem that the param parts of a request were flushed when read for the
first time... so
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
I found a minor installation bug in both modperl v1.99-5. (The same bug
also seems to be in the latest modperl-2.0 CVS tree.)
The bug occurs when you try to install modperl 2 with the latest version
of Apache (2.0.42). For whatever reason, the Apache folks changed the
format of the macros
Em Wed, Sep 25, 2002 at 10:40:53AM -0700, Eugene Eric Kim escreveu:
format of the macros in include/ap_release.h between 2.0.40 and 2.0.42.
AP_SERVER_BASEREVISION is now:
#define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION . AP_SERVER_PATCHLEVEL
instead of simply:
#define
* Michael McLagan [EMAIL PROTECTED] [2002-09-21 11:45]:
There is a bug in Apache::Cookie. It doesn't handle a cookie with
zero bytes in it!
This is because Apache::Cookie is implemented in C, and C uses NULL as
the end of string terminator.
This is probably something that needs to be done
Hello,
There is a bug in Apache::Cookie. It doesn't handle a cookie with zero
bytes in it!
$value = ABCD . chr(0) . EFGH;
$cookie = Apache::Cookie-new($request, -name= 'oatmeal', -value= $value,
-domain=$ENV{'SERVER_NAME'}, -path=/);
print $cookie-as_string;
The output looks like
Once upon a time, I wrote:
There is a bug in Apache::Cookie. It doesn't handle a cookie
with zero bytes in it!
A clarification, it's not a zero length cookie that is mishandled, it's a
cookie with an embedded NUL (zero) character.
Michael
Your problem doesn't sound like something that Apache::DBI would cause.
Deadlock problems are caused by conflicting updates, which could only
be coming from your code.
I'm not positive but maybe it seemed like there were
stale handlers lying around that weren't being closed
If you put
)
the same thing printed to a file and to STDOUT (tied by
Apache::Filter), is in first case normal, in 2d case all
UTF-8.
this was with activestate build 631
the bug disappeared with activestate build 633
Pascal
Accédez au courrier électronique de La Poste : www.laposte.net
Hi! I recently made an attempt to upgrade other web software to
mod_perl 1.26 (compiled statically, running on Solaris 2.6). We're
using Sybase 11.9.2 for this application as the db backend. When I
initially converted the site over to mod_perl, I started off using
Apache::DBI by placing it
Hi
under perl561/modperl 1
I have 2 modules in an apache filter context
perlhandler module1 module2
module1 prints some text
partly hardcoded normal (but accented) text
partly from an XML::XPath instruction (UTF-8 codeset but
inside the ascii 127)
- if module1 is alone the output is ok
-
I am an idiot. Please ignore the previous post.
Richard :(
- Original Message -
From: Richard Clarke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 2:00 AM
Subject: (browser bug) Internet Explorer AuthCookie and others
List,
I just wanted to post to see
Greetings.
On Fri, Jun 14, 2002 at 12:44:50PM +0200, Alessandro Forghieri wrote:
Running NT4SP6, 5.8RC1 compiled debug.
The following session:
D:\Apache2perl -d -e 42
DB1 ;{use threads;my $var=1;threads-create(sub{$var++})-join();}
Crashes the intepreter, in perl.c:
[...]
Sorry to
In UNIX platforms your test made Perl enter a 100% CPU loop consisting
of SEGVs on top of SEGVs on top of SEGVS... the below hopefully fixes:
Change 17250 by jhi@alpha on 2002/06/15 15:34:51
Possible cure for
Subject: Re: Thread bug in 5.8RC1 Win32
From
Greetings.
Running NT4SP6, 5.8RC1 compiled debug.
The following session:
D:\Apache2perl -d -e 42
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(-e:1): 42
DB1 ;{use threads;my
hi
this problem is very very very persistent
httpd.conf
PerlModule DBI # THIS IS THE PROBLEM
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
i try all
rebuild modperl witch modperl
/Lexmark)
Subject: Re: DBI Bug
i using last version of DBI
bye
nattis
1 - 100 of 421 matches
Mail list logo
