Oops, I've sent this mail a bit too fast...
As usual, all three binary versions are available here :
http://nicolas.lehuen.com/download/mod_python/
Regards,
Nicolas
2006/2/20, Nicolas Lehuen [EMAIL PROTECTED]:
+1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4
+1
Hi Oden,
The Apache 2.2 support will likely go into the 3.2.9 bugfix release. We
just wanted to get the security problem out of the way first.
Jim
Oden Eriksson wrote:
+1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2
Note that I applied this change:
+1 core vote
Jim
Gregory (Grisha) Trubetskoy wrote:
Based on summary below, +1 from for putting it out there.
Grisha
Graham Dumpleton [EMAIL PROTECTED]
+1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN
trunk)
Nicolas Lehuen [EMAIL PROTECTED]
+1 mod_python 3.2.8 +
+1 core vote
2006/2/20, Jim Gallacher [EMAIL PROTECTED]:
+1 core vote
Jim
Gregory (Grisha) Trubetskoy wrote:
Based on summary below, +1 from for putting it out there.
Grisha
Graham Dumpleton [EMAIL PROTECTED]
+1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x
+1 core vote
Nicolas Lehuen wrote ..
+1 core vote
2006/2/20, Jim Gallacher [EMAIL PROTECTED]:
+1 core vote
Jim
Gregory (Grisha) Trubetskoy wrote:
Based on summary below, +1 from for putting it out there.
Grisha
Graham Dumpleton [EMAIL PROTECTED]
+1 Mac OS X
Hi Michel,
I've tested your patch on Win32 + Apache 2.2 and it mostly works
(compilation + unit tests) - except for the changes in the PSP lexer
parser. They now includ unistd.h which was previously hidden for Win32
platforms.It looks like you have generated those files from the .l
grammar using
Er... I should say that the changes in _pspmodule.c are fine, so they
should be integrated. The problems are in the changes brought to the
files that are generated by flex. First, they break on Win32, second,
since the .l source file is unchanged, next time flex is run the
changes will be
Now that we've got a release of libapreq2
out the door, it's a good time to think about
the direction of the project going forward.
So let's take a look at where we are now,
and figure out where we want to be in a year
from now, and map out some goals for getting
there.
Right now we have a
I'd love to see libapreq2 in httpd base and the perl glue in mod_perl
asap
i think it would be best for all three projects.
On Feb 20, 2006, at 2:25 PM, Joe Schaefer wrote:
Now that we've got a release of libapreq2
out the door, it's a good time to think about
the direction of the
Eli Marmor wrote:
Hi Joe,
First, congrats and thanks for 2-2.07.
Everything sounds great (well, maybe except for the words that may
take some time doing ;-)
My question: currently, there is one big libapreq2-2.07.tar.gz; Why
don't we split it into two files, one for the C glue, a candidate
Geoffrey Young wrote:
I think that's a good idea, so long as [EMAIL PROTECTED]
can withstand the occasional question about our
perl glue. Someday I'd actually like to see
trunk/glue/perl moved over to mod_perl's trunk,
and our C code folded into httpd somehow, but
that may take some time
On Wed, Feb 15, 2006 at 04:44:43PM -, Jim Jagielski wrote:
Author: jim
Date: Wed Feb 15 08:44:42 2006
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger
-Ursprüngliche Nachricht-
Von: Joe Orton
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger Pluem, Jim Jagielski]
Also, document previous
On Mon, Feb 20, 2006 at 10:53:27AM +0100, Plüm, Rüdiger, VIS wrote:
Von: Joe Orton
New Revision: 378032
URL: http://svn.apache.org/viewcvs?rev=378032view=rev
Log:
*) mod_proxy: Fix KeepAlives not being allowed and set to
backend servers. PR38602. [Ruediger Pluem, Jim
+1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5
I used the 3.2.x branch out of SVN rather than the tar ball though.
Graham
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
Maybe Jim's build didn't include mod_ssl? r378032 is the most recent
change
On Mon, Feb 20, 2006 at 11:30:02AM +0100, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
-Ursprüngliche Nachricht-
Von: Joe Orton
Could you please give the following patch a try?
That fixed most of the failures, there are still two left:
OK. That gives a better idea what possibly goes wrong.
t/ssl/proxyok 61/172# Failed test 62 in t/ssl/proxy.t at line 112
On Mon, Feb 20, 2006 at 12:52:31PM +0100, Plüm, Rüdiger, VIS wrote:
I found only one pertinent error message in the log:
[Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP:
connection complete to 127.0.0.1:8529 (localhost.localdomain)
But this is HTTP to the backend
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
Based on summary below, +1 from for putting it out there.
Grisha
Graham Dumpleton [EMAIL PROTECTED]
+1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk)
Nicolas Lehuen [EMAIL PROTECTED]
+1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4
+1
Small idea: should we adjust
ap_proxy_http_cleanup() to accept a status value,
and thus make that logic internal to it? That
is, have an OK/NOK conditional aspect to
ap_proxy_http_cleanup()? I think it would be
useful at the other places were we use it...
PS: I'm planning to be offline for the
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain some sort
of local state-of-health on the socket pre-and-post
each
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain
Plüm wrote:
I think the SSL problem is caused by throwing away the conn_rec
entry for the backend and create a new one for each request.
That does not sound right, but I admit that keeping it must be
carefully examinated due to several possible issues. Two
that I can see immeditately are:
+1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2
Note that I applied this change:
http://issues.apache.org/jira/browse/MODPYTHON-78
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
-Ursprüngliche Nachricht-
Von: Jim Jagielski
term. Might be easier if we have a http / https client
library as part
of httpd or apr-util.
This only helps http, not ajp/fcgi or other protocols.
True, but ajp already does not use the fake conn_rec / request_rec stuff.
Instead
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
term. Might be easier if we have a http / https client=20
library as part=20
of httpd or apr-util.
=20
This only helps http, not ajp/fcgi or other protocols.
True,
On 02/20/2006 06:38 PM, Jim Jagielski wrote:
=20
This only helps http, not ajp/fcgi or other protocols.
True, but ajp already does not use the fake conn_rec / request_rec =
stuff.
Instead it works directly on the socket, or better the code in ajp* =
works
directly on the socket and
Hi Joe,
First, congrats and thanks for 2-2.07.
Everything sounds great (well, maybe except for the words that may
take some time doing ;-)
My question: currently, there is one big libapreq2-2.07.tar.gz; Why
don't we split it into two files, one for the C glue, a candidate for
the integration
On 02/20/2006 05:17 PM, Plüm wrote:
For me that puts the question on the table if using fake request_rec
and conn_rec structures for the backend connections is really a good
idea. This misuse already leads to problems in other areas.
Of course I should point a reference :-):
I think that's a good idea, so long as [EMAIL PROTECTED]
can withstand the occasional question about our
perl glue. Someday I'd actually like to see
trunk/glue/perl moved over to mod_perl's trunk,
and our C code folded into httpd somehow, but
that may take some time doing.
in principle I
0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1
I have a problem to build mod_pyton on Tru64 with the Python config I have.
This is basically due to the fact that Python.h should be included first as
its defines some macros used by standard includes. When included at the end
of the
On 02/20/2006 02:51 PM, Joe Orton wrote:
That's not what I meant. This is a bit tricky. Here's a restatement of
the problem, just to make sure we're talking about the same thing:
If a client reuses a connection to an HTTP server which has been held
open persistently, there is a risk
Hi Michel,
Please create a JIRA issue. We are much less likely to loose track of it
if it's in the issue tracker.
Thanks,
Jim
Michel Jouvin wrote:
0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1
I have a problem to build mod_pyton on Tru64 with the Python config I
have. This is
Hi --
I've crafted what seems to me like a reasonably minimal set of
patches to deal with the issue I described in this thread:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=113986864730305w=2
The crux of the problem is that on Linux, when using httpd with
the worker MPM (and probably
On 2/18/2006 at 4:59 pm, in message
[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Ruediger Pluem wrote:
On 02/18/2006 11:46 PM, David Reid wrote:
Ruediger Pluem wrote:
So please revert or fix.
Why are people so quick to ask for reversion these days?
Please note that I said revert *or*
Eli Marmor [EMAIL PROTECTED] writes:
Hi Joe,
First, congrats and thanks for 2-2.07.
Everything sounds great (well, maybe except for the words that may
take some time doing ;-)
My question: currently, there is one big libapreq2-2.07.tar.gz; Why
don't we split it into two files, one for
Python.h should be included first
-
Key: MODPYTHON-138
URL: http://issues.apache.org/jira/browse/MODPYTHON-138
Project: mod_python
Type: Bug
Components: core
Versions: 3.2
Environment: Tru64 5.1B, Python 2.4.1, Apache
On 02/20/2006 11:50 AM, Joe Orton wrote:
Maybe. Got another idea in the meantime. Maybe it is because we use the same
socket to a backend, but we create a new conn_rec each time for this backend
and thus try to reinit the existing ssl connection. Could you please give the
following patch a
[ http://issues.apache.org/jira/browse/MODPYTHON-138?page=all ]
Michel Jouvin updated MODPYTHON-138:
Attachment: mod_python-3.2.6-tru64.patch
Diff file containing changes implemented to fix the issue described. Built for
3.2.6 but should probably
[EMAIL PROTECTED] wrote:
@@ -1672,6 +1672,14 @@
backend-is_ssl = is_ssl;
+/*
+ * TODO: Currently we cannot handle persistent SSL backend connections,
+ * because we recreate backend-connection for each request and thus
+ * try to initialize an already existing
On 2/20/06, Sander Striker [EMAIL PROTECTED] wrote:
For me that puts the question on the table if using fake request_rec
and conn_rec structures for the backend connections is really a good
idea. This misuse already leads to problems in other areas.
But reworking this will take much time
On 2/19/06, Jim Gallacher [EMAIL PROTECTED] wrote:
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this is
an error and that *everything* should be version 2.0?
Yes. -- justin
44 matches
Mail list logo
