Quetzalcoatl

[Gregory (Grisha) Trubetskoy]

Just so that many of you do not wonder "We are a TLP - where is it???"

Everything is well. :)

It's just turned out that selecting "python.apache.org" as the main 
destination for it is not something that everyone is in agreement on and 
quite a bit of discussion had to take place, and we're still in the 
process, but it will all hopefully be resolved soon now.


Grisha

Apache Board Meeting, June 20, 2007 (fwd)

[Gregory (Grisha) Trubetskoy]

Well - it's official now, we're Quetzalcoatl. Congrats and thanks to all 
for the hard work! I am certain that this change will result in many more 
exciting developments in the future. :)


Next order of things will be infrastructural changes - establishing a 
solaris zone, mailing lists, etc.


I will be out of reach of even cell phones until next Wednesday taking 
some time off, and when I return we will continue working on this, though 
the former 'core team' folks can feel free to start this while I'm out.


Regards,

Grisha

-- Forwarded message --
Date: Wed, 20 Jun 2007 12:45:06 -0700
From: Greg Stein <[EMAIL PROTECTED]>
Subject: Apache Board Meeting, June 20, 2007 (new officers!)

[SNIP]

We also established new three projects:

* Apache Quetzalcoatl: this springs mod_python and related bits out of
the HTTPD project into its own TLP. Gregory Trubetskoy is its Chair.

[SNIP]

Re: TLP Name

[Gregory (Grisha) Trubetskoy]

Quetzalcoatl is the winner.

Grisha


On Tue, 22 May 2007, Rob Sanderson wrote:




+1 Quetzalcoatl

And ditto re pyFoo and kFoo. :)

Rob

On Tue, 2007-05-22 at 12:08 -0400, Jim Gallacher wrote:

+1 Quetzalcoatl

I think I voted 3 times for different things, so this is my *final*
official vote. ;)

I'm not a fan of pypache for the same reasons that others have stated.
Projects that stick py, q, k or gnu on the front of the name have always
bugged me.

Jim

Gregory (Grisha) Trubetskoy wrote:



So far PyPache seems to be the winner. Terranium is second, Quetzalcoatl
thrid.

Let's say this vote closes on Wednesday, and please send in +1's for one
name - statements like "I like both  and " are hard to
account for.


On Fri, 18 May 2007, Clodoaldo wrote:


+1 pypache

2007/5/17, Daniel J. Popowich <[EMAIL PROTECTED]>:


 +1 on pypache





--
Clodoaldo Pinto Neto

Re: TLP Name

[Gregory (Grisha) Trubetskoy]

On Sun, 20 May 2007, Justin Erenkrantz wrote:

FWIW, the full name of the TLP will be: "Apache " - so "Apache 
PyPache" doesn't roll off the tongue very well...


Yes, Apache PyPache does sound a bit silly. My vote is then:

+1 Quetzalcoatl

Those who have not voted yet (there are hundreds of you, I know) PLEASE 
keep on sending in your votes.


Grisha

Re: TLP Name

[Gregory (Grisha) Trubetskoy]

So far PyPache seems to be the winner. Terranium is second, Quetzalcoatl 
thrid.


Let's say this vote closes on Wednesday, and please send in +1's for one 
name - statements like "I like both  and " are hard to 
account for.



On Fri, 18 May 2007, Clodoaldo wrote:


+1 pypache

2007/5/17, Daniel J. Popowich <[EMAIL PROTECTED]>:


 +1 on pypache





--
Clodoaldo Pinto Neto

Re: TLP Name

[Gregory (Grisha) Trubetskoy]

On Thu, 17 May 2007, Jim Gallacher wrote:


Quetzalcoatl is still my sentimental favourite.

Perhaps I'm overly concerned with potential search problems for 
Quetzalcoatl, considering that Google is pretty good at figuring out 
spelling errors. Also the mod_python name will not disappear, as it'll 
still be used as a subproject name, so people can find us that way.


Yep. I don't think the TLP itself will be searched for, it's always going 
to be subprojects, and most likely over time a search for "Apache Python" 
will take you there (like it does for mod_python currently). And of course 
there is the spelling correction.


Grisha

Re: TLP Name

[Gregory (Grisha) Trubetskoy]

I like Quetzalcoatl and PyPache. Terrarium seemed nice at first, but then 
the ophidiophobia in me took over. (Nobody suggested ophis, btw..)


On Wed, 16 May 2007, Gregory (Grisha) Trubetskoy wrote:



So I think we've got (in no particular order):

PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi

Would people (ANYONE here on the list, yes, that includes *YOU*) please 
respond with the one they like most and I will compile the results?


Thanks!

Grisha

TLP Name

[Gregory (Grisha) Trubetskoy]

So I think we've got (in no particular order):

PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi

Would people (ANYONE here on the list, yes, that includes *YOU*) please 
respond with the one they like most and I will compile the results?


Thanks!

Grisha

ANNOUNCE: Mod_python 3.3.1

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.1 release of mod_python. Mod_python 3.3.1
is considered a stable release, suitable for production use.

Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd
internals, content filters and connection handlers.

The 3.3.1 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. See Appendix A
of mod_python documentation for more details.

Mod_python 3.3.1 is released under the new Apache License version 2.0.

Mod_python 3.3.1 is available for download from:

http://httpd.apache.org/modules/python-download.cgi

More infromation about mod_python is available at:

http://httpd.apache.org/modules/

Many thanks to everyone who contributed to and helped test
this release, without your help it would not be possible!

Regards,

The Apache Mod_python team.

Re: [VOTE] does mod_python want to be a TLP

[Gregory (Grisha) Trubetskoy]

Sorry - for technical reasons (serious home server crash) I missed this 
thread entirely, and for the same reason i'm lagging on the releasing 
mod_python that's ready to go.


I am for making mod_python a TLP, and I also support Jim's suggestion of 
making it more general. So a late +1.


I didn't see any suggestion of who the person interfacing with the board 
would be - i'd be happy to be it, as with my current schedule i'm probably 
only good for "administrative" tasks of this sort anyhow.


P.S. Also agree with Graham re modpython.org site - but that's an issue 
not related to python being TLP, it's just that some day someone needs to 
do the work of migrating the mailing list and its archive and the site to 
apache infra.


Grisha


On Sun, 11 Feb 2007, Roy T. Fielding wrote:


On Feb 7, 2007, at 6:47 PM, Roy T. Fielding wrote:

The vote shall be open 72 hours or until all of the mod_python
core group members have voted, whichever is earlier.


Well, I didn't get enough responses, so this will have to wait
until after folks figure out what to do next.

Roy

Re: Core vote for 3.3.1 stable release

[Gregory (Grisha) Trubetskoy]

I just got back from Nicolas's country where my 'net access was a bit 
spotty, but everything else was great (but expensive) as always... :-)


core +1 from me

as soon as i get over the jetlag and catch up with things, i'll do the 
rest (we have all the core votes, right?)


grisha

On Thu, 1 Feb 2007, Nicolas Lehuen wrote:


Following my tests on Windows, and knowing that 3.3.1 = 3.3.0b + a
version number change, I give my +1 on the release.

Regards,
Nicolas

2007/2/1, Jim Gallacher <[EMAIL PROTECTED]>:

I think we have sufficiently tested 3.3.1 and it is time for the core
group to vote on a release.

This vote is only open to the mod_python core group (Grisha, Nicolas,
Graham and myself) and is binding. We need at least three +1 votes for
the release to proceed. A -1 from any of the four voters will veto the
release.

And here is my vote:

+1 Release 3.3.1 for General Availability

Jim

ANNOUNCE: Mod_python 3.3.0b (Beta)

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.0b (Beta) release of mod_python.

Version 3.3.0b of mod_python features several new functions and
attributes providing better access to apache internals, as well as
many bug fixes and various performance and security improvements. A
detailed description of the changes is available in Appendix A of the
mod_python manual, also available here

http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-from-3.2.10.html

Beta releases are NOT considered stable and usually contain bugs.

This release is intended to solicit widespread testing of the code. We
strongly recommend that you try out your existing applications and
experiment with new features in a non-production environment using
this version and report any problems you may encounter so that they
can be addressed before the final release.

Preferred method of reporting problems is the mod_python user list
[EMAIL PROTECTED]

Mod_python 3.3.0b is available for download from:

http://httpd.apache.org/modules/python-download.cgi

For more information about mod_python visit http://www.modpython.org/

Regards,

The Apache mod_python team.

Re: Core vote [Re: mod_python 3.3.0 beta available for testing]

[Gregory (Grisha) Trubetskoy]

Sorry it took a little long, 3.3.0b is out there, and the web page has 
been updated.


The proposed announcement follows, I'll be sending it out some time over 
X-Mas, please respond before then if you think something needs to be 
added/changed:



Subject: ANNOUNCE: Mod_python 3.3.0 Beta

The Apache Software Foundation and The Apache HTTP Server Project are 
pleased to announce the 3.3.0 Beta release of mod_python.


Version 3.3.0b of mod_python features several new functions and attributes 
providing better access to apache internals, as well as many bug fixes and 
various performance and security improvements. A detailed description of 
the changes is available in Appendix A of the mod_python manual, also 
available here


http://www.modpython.org/live/mod_python-3.3.0b/doc-html/app-changes-from-3.2.10.html

Beta releases are NOT considered stable and usually contain bugs.

This release is intended to solicit widespread testing of the code. We 
strongly recommend that you try out your existing applications and 
experiment with new features in a non-production environment using this 
version and report any problems you may encounter so that they can be 
addressed before the final release.


Preferred method of reporting problems is the mod_python user list 
[EMAIL PROTECTED]


Mod_python 3.3.0b is available for download from:

http://httpd.apache.org/modules/python-download.cgi

For more information about mod_python visit http://www.modpython.org/

Regards,

The Apache mod_python team.



On Fri, 15 Dec 2006, Jim Gallacher wrote:


Gregory (Grisha) Trubetskoy wrote:


I concur - my +1 was for a beta


+1 for 3.3.0 beta

Jim



grisha

On Wed, 13 Dec 2006, David Fraser wrote:

I'm not "core" but I think its good practice to officially release this 
as a beta to the wider community before making it an actual release.

I didn't test it because I was waiting for the core vote :-)

David

Jim Gallacher wrote:

Gregory (Grisha) Trubetskoy wrote:
>
> core +1 on releasing it into the wild
>
> grisha

I'm not sure what we're voting on here, and I'm not sure what I meant 
by "the next level" either. :)


Is this a vote to give 3.3.0 beta a wider release (apache mirrors and 
so on), or a vote to go right to the 3.3.0 final release?


I'm +1 either way. As I recall we didn't get much additional testing 
as a result of uploading the betas to the apache mirrors in the past. 
The people most likely to chip in with testing are already here on 
python-dev.


Having the 3.2.x stable branch certainly facilitated releasing quick 
fixes for 3.2. There is no reason why we can't do the same with 3.3, 
so my inclination is to do an official 3.3.0 final release now rather 
than later.


Jim



On Mon, 11 Dec 2006, Jim Gallacher wrote:

Test results so far, FYI. How long shall we wait until we kick it 
up to the next level?

- jim


+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge, Apache 2.0.54 (mpm-prefork), Python 
2.3.5

+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
+1 Linux Fedora Core 5 (i386), Apache 2.2.2 (mpm-prefork), Python 
2.4.3
+1 Linux Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 
2.4.3

+1 Linux Fedora Core 6, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Fedora Core 6 i386, Apache 2.2.3 (mpm-prefork), Python 
2.4.4
+1 Linux Fedora Core 6 x86_64, Apache 2.2.3 (mpm-prefork), Python 
2.4.4

+1 Linux Slackware 10.2, Apache 2.2.3 (mpm-prefork), Python 2.4.1
+1 Linux Ubuntu 6.0.6, Apache 2.0.55 (mpm-worker), Python 2.4.3
+1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1
+1 Mac OS X (Darwin 8.8.1), Apache 2.2.3 (mpm-prefork), Python 
2.4.2
+1 Mac OS X (PowerPC), Apache 2.2.1 (mpm-worker), Python 2.3.5 (OS 
Supplied Version)
+1 Mac OS X (PowerPC), Apache 2.0.55 (mpm-worker), Python 2.3.5 
(OS Supplied Version)

+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.4
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.4

Re: Core vote [Re: mod_python 3.3.0 beta available for testing]

[Gregory (Grisha) Trubetskoy]

I concur - my +1 was for a beta

grisha

On Wed, 13 Dec 2006, David Fraser wrote:

I'm not "core" but I think its good practice to officially release this as a 
beta to the wider community before making it an actual release.

I didn't test it because I was waiting for the core vote :-)

David

Jim Gallacher wrote:

Gregory (Grisha) Trubetskoy wrote:
>
> core +1 on releasing it into the wild
>
> grisha

I'm not sure what we're voting on here, and I'm not sure what I meant by 
"the next level" either. :)


Is this a vote to give 3.3.0 beta a wider release (apache mirrors and so 
on), or a vote to go right to the 3.3.0 final release?


I'm +1 either way. As I recall we didn't get much additional testing as a 
result of uploading the betas to the apache mirrors in the past. The 
people most likely to chip in with testing are already here on python-dev.


Having the 3.2.x stable branch certainly facilitated releasing quick fixes 
for 3.2. There is no reason why we can't do the same with 3.3, so my 
inclination is to do an official 3.3.0 final release now rather than 
later.


Jim



On Mon, 11 Dec 2006, Jim Gallacher wrote:

Test results so far, FYI. How long shall we wait until we kick it up 
to the next level?

- jim


+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge, Apache 2.0.54 (mpm-prefork), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
+1 Linux Fedora Core 5 (i386), Apache 2.2.2 (mpm-prefork), Python 
2.4.3

+1 Linux Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 2.4.3
+1 Linux Fedora Core 6, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Fedora Core 6 i386, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Fedora Core 6 x86_64, Apache 2.2.3 (mpm-prefork), Python 
2.4.4

+1 Linux Slackware 10.2, Apache 2.2.3 (mpm-prefork), Python 2.4.1
+1 Linux Ubuntu 6.0.6, Apache 2.0.55 (mpm-worker), Python 2.4.3
+1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1
+1 Mac OS X (Darwin 8.8.1), Apache 2.2.3 (mpm-prefork), Python 2.4.2
+1 Mac OS X (PowerPC), Apache 2.2.1 (mpm-worker), Python 2.3.5 (OS 
Supplied Version)
+1 Mac OS X (PowerPC), Apache 2.0.55 (mpm-worker), Python 2.3.5 
(OS Supplied Version)

+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.4
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.4

Core vote [Re: mod_python 3.3.0 beta available for testing]

[Gregory (Grisha) Trubetskoy]

core +1 on releasing it into the wild

grisha

On Mon, 11 Dec 2006, Jim Gallacher wrote:

Test results so far, FYI. How long shall we wait until we kick it up to the 
next level?

- jim


+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge, Apache 2.0.54 (mpm-prefork), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
+1 Linux Fedora Core 5 (i386), Apache 2.2.2 (mpm-prefork), Python 2.4.3
+1 Linux Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 2.4.3
+1 Linux Fedora Core 6, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Fedora Core 6 i386, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Fedora Core 6 x86_64, Apache 2.2.3 (mpm-prefork), Python 2.4.4
+1 Linux Slackware 10.2, Apache 2.2.3 (mpm-prefork), Python 2.4.1
+1 Linux Ubuntu 6.0.6, Apache 2.0.55 (mpm-worker), Python 2.4.3
+1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1
+1 Mac OS X (Darwin 8.8.1), Apache 2.2.3 (mpm-prefork), Python 2.4.2
+1 Mac OS X (PowerPC), Apache 2.2.1 (mpm-worker), Python 2.3.5 (OS Supplied 
Version)
+1 Mac OS X (PowerPC), Apache 2.0.55 (mpm-worker), Python 2.3.5 (OS 
Supplied Version)

+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.4
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.5
+1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.4

ANNOUNCE: Mod_python 3.2.10

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.10 release of mod_python. Mod_python
3.2.10 is considered a stable release, suitable for production use.

Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd
internals, content filters and connection handlers.

The 3.2.10 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. 3.2.10 now
works with Apache HTTP Server 2.2. See Appendix A of mod_python
documentation for a complete list.

Mod_python 3.2.10 is released under Apache License version 2.0.

Mod_python 3.2.10 is available for download from:

http://httpd.apache.org/modules/python-download.cgi

More information about mod_python is available at:

http://httpd.apache.org/modules/

Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and
everyone else who contributed to and helped test this release, without
your help it would not be possible!

Regards,

Grisha Trubetskoy

Re: mod_python 3.2.10 core vote

[Gregory (Grisha) Trubetskoy]

The site's been update (both mopython.org and the download page), so 
3.2.10 is out. I'll work on the announcement next.


Grisha

On Mon, 31 Jul 2006, Gregory (Grisha) Trubetskoy wrote:



Core +1 from me. I will take care of the signing, etc, some time tomorrow.

P.S. In order for you to be able to sign you need to meet in person someone 
(or probably more than one person) from ASF. ApacheCon is the best place, and 
members do not have to pay the conference fee (at least I think that it is 
still true) ;-)


Grisha

On Thu, 27 Jul 2006, Nicolas Lehuen wrote:


Just to make sure I've reinstalled my Python 2.3 test environment...

So even if I've already voted, I've got an additional

+1 Windows 2000 Server SP4, Apache 2.0.58 (mpm-winnt), Python 2.3.5

Regards,
Nicolas

2006/7/26, Nicolas Lehuen <[EMAIL PROTECTED]>:


+1 too.

2006/7/26, Jim Gallacher <[EMAIL PROTECTED]>:

> I think it's time for a core vote on the 3.2.10 release, as no more 
test

> results have appeared since Saturday.
>
> This vote is for the mod_python core only (Jim, Graham, Grisha and
> Nicolas).
>
> I am:
>
> +1 release now
>
> Jim
>
>
> Test summary:
>
> +1 Fedora Core 5, Apache 2.2.0 (mpm-prefork), Python 2.4.3
> +1 FreeBSD 6.1-RELEASE-p2 (i386), Apache 2.2.2(mpm-prefork),
> python-2.4.3
> +1 Gentoo 2006.0 (x86_64), Apache 2.2.2 (mpm-prefork), python-2.4.3
> +1 Linux Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4.1
> +1 Linux Debian Sid, Apache 2.0.55 (mpm-prefork), Python 2.3.5
> +1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2
> +1 Linux Ubuntu 6.06 Dapper Drake, Apache 2.0.55 (mpm-worker), Python
> 2.4.3
> +1 MacOSX 10.4.7 Intel, Apache 2.0.55 (mpm-prefork), Python 2.4.3
> +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-prefork), Python 2.3.5
> +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-worker), Python 2.3.5
> +1 Windows XP SP2, Apache 2.0.58 (mpm-winnt), Python 2.4.3
>

Re: mod_python 3.2.10 core vote

[Gregory (Grisha) Trubetskoy]

Core +1 from me. I will take care of the signing, etc, some time tomorrow.

P.S. In order for you to be able to sign you need to meet in person 
someone (or probably more than one person) from ASF. ApacheCon is the best 
place, and members do not have to pay the conference fee (at least I think 
that it is still true) ;-)


Grisha

On Thu, 27 Jul 2006, Nicolas Lehuen wrote:


Just to make sure I've reinstalled my Python 2.3 test environment...

So even if I've already voted, I've got an additional

+1 Windows 2000 Server SP4, Apache 2.0.58 (mpm-winnt), Python 2.3.5

Regards,
Nicolas

2006/7/26, Nicolas Lehuen <[EMAIL PROTECTED]>:


+1 too.

2006/7/26, Jim Gallacher <[EMAIL PROTECTED]>:

> I think it's time for a core vote on the 3.2.10 release, as no more test
> results have appeared since Saturday.
>
> This vote is for the mod_python core only (Jim, Graham, Grisha and
> Nicolas).
>
> I am:
>
> +1 release now
>
> Jim
>
>
> Test summary:
>
> +1 Fedora Core 5, Apache 2.2.0 (mpm-prefork), Python 2.4.3
> +1 FreeBSD 6.1-RELEASE-p2 (i386), Apache 2.2.2(mpm-prefork),
> python-2.4.3
> +1 Gentoo 2006.0 (x86_64), Apache 2.2.2 (mpm-prefork), python-2.4.3
> +1 Linux Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4.1
> +1 Linux Debian Sid, Apache 2.0.55 (mpm-prefork), Python 2.3.5
> +1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2
> +1 Linux Ubuntu 6.06 Dapper Drake, Apache 2.0.55 (mpm-worker), Python
> 2.4.3
> +1 MacOSX 10.4.7 Intel, Apache 2.0.55 (mpm-prefork), Python 2.4.3
> +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-prefork), Python 2.3.5
> +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-worker), Python 2.3.5
> +1 Windows XP SP2, Apache 2.0.58 (mpm-winnt), Python 2.4.3
>

Core Vote (Re: mod_python 3.2.9 available for testing)

[Gregory (Grisha) Trubetskoy]

Sorry for the late response - I was trying to have a "vacation" - that's 
when you are geographically in a different place with slow internet access 
and read only "some" of your e-mail ;-)


+1 for core vote (with the note about the 2.2.2 XP SP2 issue).

Grisha

On Sat, 8 Jul 2006, Graham Dumpleton wrote:



On 08/07/2006, at 4:26 AM, Jim Gallacher wrote:


Hi Grisha,

Here is the tally:

+1 FreeBSD 6.1-RELEASE-p2, Apache 2.2 (mpm-prefork), Python 2.4.3
+1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5
+1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2
+1 Linux Fedora Core 5 (i386), Apache 2.2.0 (mpm-prefork), Python 2.4.3
+1 Linux Slackware 10.2, Apache 2.0.55 (mpm-prefork), Python 2.4.1
+1 Linux Ubuntu 6.06, Apache 2.0.55 (mpm-worker), Python 2.4.3
+1 MacOSX 10.4.6 PPC, Apache-2.0.55 (mpm/worker), Python-2.3.5
+1 MacOSX 10.4.6 PPC, Apache-2.2.1 (mpm/worker), Python-2.3.5
+1 MacOSX 10.4.7 Intel, Apache-2.0.55 (mpm/prefork), Python-2.4.2
+1 Windows XP SP2, Apache 2.0.58 (mpm_winnt), Python 2.4.3

-1 Windows XP SP2, Apache 2.2.2 (mpm_winnt), Python 2.4.3

The -1 was from Nicolas, with the following comment:
"Only two tests fail but with a segfault, it's test_srv_register_cleanup
and test_apache_register_cleanup. This is not really surprising... I
think we should go ahead and release the 3.2.9 version, while filing a
known bug regarding the fact that we drop the support for those two
functions. If we accept this, then it's a +1.


The issue with server cleanups failing and why is covered by:

 http://issues.apache.org/jira/browse/MODPYTHON-109


The last test results were submitted July 1, so I think we may as well
have a core vote.

Jim

Gregory (Grisha) Trubetskoy wrote:


I'm barely keeping my head above water right now with work, so not
really following the list - if someone could please ping me when/if you
think we're ready for the core group vote and we have a tally.

Thanks!

Grisha

-- Forwarded message --
Date: Sat, 01 Jul 2006 23:18:05 -0400
From: Jorey Bump <[EMAIL PROTECTED]>
To: python-dev@httpd.apache.org
Subject: Re: mod_python 3.2.9 available for testing

+1 Linux Slackware 10.2, Apache 2.0.55 (mpm-prefork), Python 2.4.1

Jim Gallacher wrote:

The mod_python 3.2.9 tarball is available for testing.

This tarball is unchanged from 3.2.9-rc3, but should be retested 
anyway
- just in case something went pair-shaped in the process of tagging 
and

packaging.

Here are the rules:

In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to 
_this_

 list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).

The files are (temporarily) available here:

http://people.apache.org/~jgallacher/mod_python/dist/
http://people.apache.org/~jgallacher/mod_python/dist/ 
mod_python-3.2.9.tgz
http://people.apache.org/~jgallacher/mod_python/dist/ 
mod_python-3.2.9.tgz.md5



Please download it, then do the usual

$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install

Then (as non-root user!)

$ cd test
$ python test.py

And see if any tests fail. If they pass, send a +1 to the list, if 
they
fail, send the details (the versions of OS, Apache, Apache-mpm, 
Python,

the test output, and suggestions, if any).

Please present your test results in the following format:
+1 OS version, Apache version (apache mpm), Python Version

For example:
+1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5

Presenting your information in a consistent format will help in
tabulating the results. You can include additional information in each
section, just don't use extra commas. There is no need to include the
mod_python version in this string as that information is available in
the email subject. Who knows, one day I may actually write a script to
extract this information automatically. :)

Thank you for your assistance,
Jim Gallacher

Re: release 3.2.10?

[Gregory (Grisha) Trubetskoy]

On Tue, 18 Jul 2006, Jim Gallacher wrote:


For 3.2.9 I called for 2 rounds of testing: one for the release
candidate and one for the final tarball. Do folks here feel that is
necessary for 3.2.10 or should I just jump right to the 3.2.10 final?
That tarball would still be subject to a vote on this list before an
official release. Cutting out the first step will save a few days.


I think what you term it doesn't matter - if it's voted down, it will be 
voted down, be it 3.2.10 RC or 3.2.10 Final (we'll just have to make a 
3.2.11 then).


So just go for it :-)

Grisha

Re: release 3.2.10?

[Gregory (Grisha) Trubetskoy]

I'm +1 on going for 3.2.10.

You in Canada probably have it easier - I think we hit 96F/35C at some
point today or yesterday (I wouldn't know I'm in the office which has AC 
sunrise to sunset, I just listen to the news), and unfortunately (or not) 
due to work pressures I have no time for anything - no frolicking for me 
this summer :-(


Grisha

On Sun, 16 Jul 2006, Jim Gallacher wrote:


Graham Dumpleton wrote:

Jim Gallacher wrote ..

Shall we proceed with a 3.2.10 release with the current memory leak
fixes, or keep digging for more leaks?

Seeing as it's summer for most of us (except for Graham), I get the
feeling people don't have a lot of free time to spend on mod_python
right now.


Just because it is winter down here and I'm freezing my butt off doesn't
mean I am any less busy. :-(


Oh, I wasn't suggesting you were any less busy - just that folks in the
northern hemisphere may well choose to frolic in the summer sun rather
that hack away at mod_python in their spare time. :)

Jim

new mod_python faq (fwd)

[Gregory (Grisha) Trubetskoy]

This was sent to me directly, anyone willing to act on it? (I don't have 
the CPU cycles right now).


-- Forwarded message --
Date: Mon, 17 Jul 2006 18:12:07 +0200
To: [EMAIL PROTECTED]
Subject: new mod_python faq

I think may be useful to add this question:

2.30. Why do I get "No space left on device: Failed to create global
mutex" ?

Because mod_python has get all the available semaphores of your os.
To avoid this error on GNU/Linux do
#ipcs (to see all locked semaphores)
#for i in `ipcs | grep "www-data" | awk '{print $2}'`; do ipcrm -s $i;
done

www-data is the user which runs apache[12] (in Debian)
In this way you release all resources locked by apache[12]

If you want to increase the number of available semaphores append
kernel.sem = 512 32000 100 512
to your /etc/sysctl.conf
and do
#sysctl -p

--
Some of the content has benne derived from
http://www.modpython.org/pipermail/mod_python/2005-April/017858.html

You can change anything you want of course :)
Thank you for the great work
(even if configuring mod_python in debian is painfully... )

Re: Auto updating of req.finfo when req.filename changed.

[Gregory (Grisha) Trubetskoy]

On Sun, 26 Mar 2006, Graham Dumpleton wrote:

One use for it that I already have is to get around the DirectoryIndex 
problems in mod_python caused by Apache's use of the 
ap_internal_fast_redirect() function to implement that feature. The 
specifics of this particular issue are documented under:


 http://issues.apache.org/jira/browse/MODPYTHON-146



Could we zoom in this a little bit. I've read the description, but not 
quite sure I understand it quite yet. Is "the problem" that if I set 
req.notes['foo'] = 'bar' in a phase prior to fixup, by the time we get to 
the content handler, it will be gone because notes would be overwritten by 
mod_dir?


Grisha

Re: Auto updating of req.finfo when req.filename changed.

[Gregory (Grisha) Trubetskoy]

I'm -1 on updating req.finfo when req.filename is updated. I don't have 
the time to explain it in detail, but I think it flows from Graham's 
explanation below.


Basically, httpd does a stat() for you, and its result is stored in finfo. 
Why make it any more complicated and magical?


If you alter req.filename - should that imply another stat()? I don't 
think so, because the stat() is the most expensive operations in the whole 
request service process and unnecessary stats should be avoided.


I also don't see any good use case for it. If you need a stat - Python 
provides way for you to do it, there is no need to get httpd involved in 
this process.


I, of course, may be missing something obvious here, but this is my 
initial reaction. Let httpd/apr behave the way they behave - there is no 
need to "pythonize" them, especially when the Python standard library 
provides the same functionality in a "pythonic" way.


Grisha

On Sun, 26 Mar 2006, Jim Gallacher wrote:


Hi Graham,

+1 auto update req.finfo when req.filename changed.

Is there a use case where the user might change filename but not want finfo 
to change? I can't think of one, so let's save the user some work and make 
their code more robust to boot.


A point I'd like to address is your concern about mod_python differing from 
the Apache C api in implementing certain features. Personally I think our 
general concern about this is somewhat misguided. I suspect that the majority 
of our users are more concerned about the "python-ness" of mod_python rather 
than its "apache-ness", and most would never notice if we deviate slightly 
from the apache C api. Adding a method or attribute to the request object for 
example, if it's useful to *our* users, shouldn't be rejected out of hand 
just because it does not exist in the underlying api.


Jim

Graham Dumpleton wrote:

Now the mailing list is a bit quiet, I would like to see if I can get
some explicit feedback on some issues related to the inability to update
the req.finfo attribute.

Grisha, would be nice if you could respond on this issue and give some
guidance else I fear I'll never be able to progress a solution to this
issue. :-(

As explained in:

  http://issues.apache.org/jira/browse/MODPYTHON-128

although it is possible to assign a new value to req.filename, there is
no way to update req.finfo to the file stats associated with that new
value of req.filename. If one had access to the low level C API this
would normally be achieved using:

  apr_stat(&r->finfo, r->filename, APR_FINFO_MIN, r->pool);

In mod_python though, there is no way to access the function and affect
that outcome.

In mod_perl 1.0 they implemented the behaviour whereby the "finfo"
attribute was automatically updated when the "filename" attribute was
updated by a handler.

In mod_perl 2.0 they dropped this though, as they wanted to preserve
the idea that in mod_perl everything behaved exactly like the C API
they were trying to provide a 1 to 1 mapping for. Thus in mod_perl
2.0 you need to write:

  use Apache2::RequestRec ();
  use APR::Finfo ();
  use APR::Const -compile => qw(FINFO_NORM);
  $r->filename($newfile);
  $r->finfo(APR::Finfo::stat($newfile, APR::Const::FINFO_NORM, $r->pool));

As mod_python isn't attempting to provide a strict 1 to 1 mapping, it
might be argued that it could do what mod_perl 1.0 did and automatically
updated the "finfo" attribute when "filename" is updated.

The only other alternative is to add a new method to the Python request
object for which there isn't strictly speaking a direct equivalent to
in the Apache C API. That is, a method that calls apr_stat() but which
only performs it in relation to the "filename" and "finfo" attributes
in the request object itself and is not a generic routine.

Since it isn't likely that mod_python will ever provide a lower level
API for use of finfo related structures and functions and even if it
did they most likely would be distinct to the request object, the name
of the function added to the request object could still be called 
"stat()".


Thus mod_python equivalent to what mod_perl 2.0 does would be:

  req.filename = newfile
  req.stat()

This though doesn't really convey a sense of what it occurring. Thus a
more descriptive name would probably be more appropriate. For example:

  req.filename = newfile
  req.update_finfo()

There is no ap_update_finfo() function now, but if they did later
implement one, this would shadow it and prevent it being added to the
request object if it was pertinent for that be done.

The next problem is that apr_stat() actually takes an argument indicating
what fields in the "finfo" attribute should be updated. In mod_perl 1.0
the value used when the automatic update was done was APR_FINFO_MIN
which results in type, mtime, ctime, atime, size being updated. In
the documentation for mod_perl 2.0 it suggests use of APR_FINFO_NORM
instead which is described as intended to be used when an atomic unix
apr_stat() is required 

Cross-platform query: _FILE_OFFSET_BITS in python and httpd

[Gregory (Grisha) Trubetskoy]

Could folks with access to different OS's try the following:

Compare output of "apxs -q CPPFLAGS" with the value of _FILE_OFFSET_BITS 
in pyconfig.h.


For example, on my Fedora Core 4 i386 system (stock httpd and python):

$ /usr/sbin/apxs -q CPPFLAGS
-DSSL_EXPERIMENTAL_ENGINE

[note - no mention of _FILE_OFFSET_BITS above]


$ grep _FILE_OFFSET_BITS /usr/include/python2.4/pyconfig.h
#define _FILE_OFFSET_BITS 64


In case you're wondering, this is in relation to 
https://issues.apache.org/jira/browse/MODPYTHON-138
and to some degree https://issues.apache.org/jira/browse/MODPYTHON-20 and 
probably a few other "unexplained" issues.


What the output on Fedora Core 4 means is that essentially Python and 
APR/httpd are compiled in an incomatible way - in APR the size of an inode 
(ino_t) is 32 bits and in Python it is 64 bits (this is what 
_FILE_OFFSET_BITS 64 does).


This issue goes unnoticed when Python.h is included after http.h, but 
becomes very obvious if you put Python.h before http.h - httpd will 
segfault on the first request because the request_rec (which includes 
finfo, which includes ino_t inode) becomes incompatible between httpd and 
mod_python and anything past finfo in request_rec structure is junk (off 
by 4 bytes).


I wanted to see how widespread this problem is. I think the right solution 
is for configure to catch this (exactly how to best detect this I'm not 
yet sure) and stop cold.


Thanks,

Grisha

Re: get_session(), req.session, req.form and MODPYTHON-38

[Gregory (Grisha) Trubetskoy]

On Mon, 13 Mar 2006, Jim Gallacher wrote:

The idea of something like req.get_session() is to give users an obvious way 
to grab a session object without the deadlock concerns. How many times have 
we seen this kind of problem-code on the mailing list?


def index(req):
   sess = Session.Session(req)
   do_stuff(req)
   ...

def do_stuff(req):
   sess = Session.Session(req)
   ... do other stuff.

Having the session constructor check for the existence of req.session is of 
no use here. We need a way to make sure only *one* session instance is 
created per request. (Bonus marks for making it work with internal redirect).


[sorry, i only read the beginning of the message, so i might be not fully 
understanding]


Session.Session is not a constructor, just a function. But also, if it 
were, I think this can be solved with the new object's __new__() ?


Grisha

Re: get_session(), req.session, req.form and MODPYTHON-38

[Gregory (Grisha) Trubetskoy]

On Mon, 13 Mar 2006, Graham Dumpleton wrote:


Thus I want a documented convention that if a handler is going to use
util.FieldStorage, that it should before doing so, first check whether
an existing instance resides as req.form and use that instead.


I'm not sure if this is a good example - req.form is something specific to 
the publisher. Rather than perhaps documenting it as you suggest, 
util.FieldStorage can take it upon itself to create a req.form so that 
subsequent attempts to instantiate it just return req.form. (This is just 
an example, I'm not 100% sure that I having FS do this makes sense - seems 
like a good idea).



Similarly, if a handler is going to create a Session object, that it
look for an existing instance as req.session and again use that instead.


OR, the Session module would know to look for a req.session, in which case 
the handlers wouldn't need to worry about it.


(One thing to watch out for would be that mutliple concurrent sessions in 
the same request is a possibility)


Grisha

Re: [jira] Assigned: (MODPYTHON-59) Add get_session() method to request object

[Gregory (Grisha) Trubetskoy]

I'm -1 on get_session() too. The request object is supposed to be a 
representation of Apache's request, and get_session() just does not belong 
there.


Grisha

On Sun, 12 Mar 2006, Jim Gallacher wrote:

I handn't really intended to start working on an implementation. I just don't 
like seeing all those issues in JIRA marked as unassigned. :) Since I created 
it I figured I should take some responsibility for it. Plus, it's a gentle 
reminder when I list my assigned issues - resolve it one way or another.


I still think we need some sort of solution to the problem of people trying 
to create 2 session instances in the same request, but I agree that the 
original concept of req.get_session() was not quite right.


Jim

Graham Dumpleton wrote:

I would rather we not go ahead with adding req.get_session() at
this time. At least not how it was envisaged to be done previously.

I'll come back with a bit of analysis after I review where we were
up to previously.

Graham

On 12/03/2006, at 8:47 AM, Jim Gallacher (JIRA) wrote:


 [ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ]

Jim Gallacher reassigned MODPYTHON-59:
--

Assign To: Jim Gallacher


Add get_session() method to request object
--

 Key: MODPYTHON-59
 URL: http://issues.apache.org/jira/browse/MODPYTHON-59
 Project: mod_python
Type: New Feature
  Components: session
Versions: 3.1.4, 3.1.3, 3.2.7
 Environment: All
Reporter: Jim Gallacher
Assignee: Jim Gallacher
 Fix For: 3.3
 Attachments: Session.py.diff.txt

Users will get session instances by calling req.get_session(). If a 
session already exists it will be returned, otherwise a new session 
instance will be created. Session configuration will be handled using 
apache directives rather than within their code.
Using this scheme means only one session instance will be created per 
request, which will eliminate the deadlock problems many people 
experience. Also, using this scheme makes it possible for sessions to 
be properly handled within psp pages and across 
req.internal_redirect() calls.

Code will be commited to svn shortly.



--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Vote on whether to integrate server side include (SSI) support.

[Gregory (Grisha) Trubetskoy]

I don't understand this enough to have an opinion on it, seems like 
another way to skin a cat, but to really form an opinion would require 
some thinking on my part at least (may be I'm getting thick with age).


I think it'd be great if those who send in +1's (or -1's) would explain 
why they think this is good, and even if it's not so useful, then is it 
worth being supported and maintained in the future.


Grisha

On Fri, 10 Mar 2006, Jim Gallacher wrote:


+1

Graham Dumpleton wrote:

I have had patches for adding server side include support into
mod_python ready for a while now. See:

  https://issues.apache.org/jira/browse/MODPYTHON-104

In short, it would add the ability to add Python code into files
being served up through the INCLUDES output filter. More
commonly this is known as server side include (SSI). For example:

   
One could say that there is an overlap between this and the

mod_python.psp handler, but the SSI feature is a builtin feature of
Apache and it make sense to support it. Using SSI, if one was mad
enough, you could even have Python and Perl code appearing in the one
file.

Anyway, the point of this email is to get a decision on whether this
major new feature should or should not be added into mod_python.

Core developer votes obviously matter the most, but others are more
than welcome to voice an opinion.

So, is it a Yes or a No?

Graham

[ANNOUNCE] Mod_python 3.2.8 (security)

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the release of version 3.2.8 of mod_python.

This release addresses a vulnerability in mod_python's FileSession
object whereby a carefully crafted session cookie could potentially
permit an attacker to execute code on the server.

FileSession was introduced in mod_python 3.2.7 released on February 15
2006 and is not enabled by default, therefore only a very small number
of installations, if any, are likely to be affected by this issue.

There are no other changes or improvements from the previous version in
this release.

Mod_python is available for download from:

http://httpd.apache.org/modules/python-download.cgi

For more information about mod_python visit http://www.modpython.org/

Regards,

Gregory Trubetskoy

[DRAFT] [ANNOUNCE] Mod_python 3.2.8 (security)

[Gregory (Grisha) Trubetskoy]

If you see any problems with this text, let me know.

-- Forwarded message --
Date: Sat, 12 Feb 2005 22:00:56 -0500 (EST)
From: "Gregory (Grisha) Trubetskoy" <[EMAIL PROTECTED]>
To: announce@httpd.apache.org, [EMAIL PROTECTED]
Cc: python-dev@httpd.apache.org
Subject: [ANNOUNCE] Mod_python 3.2.8 (security)

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the release of versions 3.2.8 of mod_python.

This release addresses a vulnerability in mod_python's FileSession
object whereby a carefully crafted session cookie could potentially
permit an attacker to execute code on the server.

FileSession was introduced in mod_python 3.2.7 released on February 15
2006 and is not enabled by default, therefore only a very small number
of installations, if any, are likely to be affected by this issue.

There are no other changes or improvements from the previous version in
this release.

Mod_python is available for download from:

http://httpd.apache.org/modules/python-download.cgi

For more information about mod_python visit http://www.modpython.org/

Regards,

Gregory Trubetskoy

Re: How mod_python treats apache.OK/apache.DECLINED response fromhandlers.

[Gregory (Grisha) Trubetskoy]

If I understand this correctly, then +1.

...though I'm wondering if anyone will actually try to do something as 
arcane as dynamicaly registering non-content handers? :-)


Grisha

On Tue, 21 Feb 2006, Jim Gallacher wrote:


Nice summary.
+1 for the change.

Jim

Graham Dumpleton wrote:

Jim Gallacher wrote ..


I don't have alot more to say on these last 2 emails. I think you are on
the right path here.



Okay, I think I have a good plan now.

To summarise the whole issue, the way Apache treats multiple handlers in
a single phase for non content handler phases is as follows:

  PostReadRequestHandler   RUN_ALL
  TransHandler RUN_FIRST
  MapToStorageHandler  RUN_FIRST
  InitHandler  RUN_ALL
  HeaderParserHandler  RUN_ALL
  AccessHandlerRUN_ALL
  AuthenHandlerRUN_FIRST
  AuthzHandler RUN_FIRST
  TypeHandler  RUN_FIRST
  FixupHandler RUN_ALL

  LogHandler   RUN_ALL

RUN_ALL means run all handlers until one returns something other than OK
or DECLINED. Thus, handler needs to return DONE or an error to have it 
stop

processing for that phase.

RUN_FIRST means run all handlers while they return DECLINED. Thus, needs
handler to return OK, DONE or error to have it stop processing for that 
phase.


Where multiple handlers are registered within mod_python for a single
phase it doesn't behave like either of these. In mod_python it will keep
running the handlers only while OK is returned. Returning DECLINED
causes it to stop. This existing behaviour can be described (like 
mod_perl)

as stacked handlers.

Having non content handler phases behave differently to how Apache does
it causes problems. For example things like a string of authentication
handlers which only say OK when they handle the authentication type,
can't be implemented properly. In Apache, it should stop the first time
one returns OK, but in mod_python it will keep running the handlers
in that phase.

In summary, it needs to behave more like Apache for the non content
handler phases.

In respect of the content handler phase itself, in practice only one 
handler

module is supposed to implement it. At the Apache level there is no
concept of different Apache modules having goes at the content handler
phase and returning DECLINED if they don't want to handle it. This is
reflected in how in the type handler phase, selection of the module to
deliver content is usually done by setting the single valued req.handler
string. Although, when using mod_python this is done implicitly by
setting the SetHandler/AddHandler directives and mod_negotiation then
in turn setting req.handler to be mod_python for you.

Because mod_python when executed for the content handler phase is
the only thing generating the content, the existing mechanism of
stacked handlers and how the status is handled is fine within just
the content handler phase. Can thus keep that as is and no chance of
stuffing up existing systems.

Where another phase calls req.add_handler() to add a handler or multiple
handlers for the "PythonHandler" (content) phase, these will be added in
a stacked manner within that phase. This also is the same as it works now.
There would be non need to have a new function to add stacked handlers
as that behaviour would be dictated by phase being "PythonHandler".

For all the non content handler phases though, the current stacked
handlers algorithm used by mod_python would be replaced with how
Apache does it. That is, within multiple handlers registered with 
mod_python

for non content handler phase, it would use RUN_FIRST or RUN_ALL
algorithm as appropriate for the phase.

For those which use RUN_ALL, this wouldn't be much different than what
mod_python does now except that returning DECLINED would cause it
to go to next mod_python handler in that phase instead of stopping.
It is highly unlikely that this change would have an impact as returning
DECLINED in RUN_ALL phases for how mod_python currently implements
it, tends not to be useful and can't see that anyone would have been using 
it.


For those which use RUN_FIRST, the difference would be significant as
reurning OK will now cause it to stop instead of going to next mod_python
handler in the phase. Personally I don't think this would be a drama as
not many people would be using these phases and highly unlikely that
someone would have listed multiple handlers for such phases. If they had
and knew what they were doing, they should have long ago realised that
the current behaviour was a bit broken and it even probably stopped them
from doing what they wanted unless they fudged it.

As to use of req.add_handler() for non content handler phases, each call
would create a distinct handler, ie., no stacking of handlers at all. No
separate function is required though, as slight change in behaviour
determine form phase specified.

To sum up, I think these changes would have minimal if no impact as
where changes are sig

Re: 3.2.8 summary / core group vote

[Gregory (Grisha) Trubetskoy]

they're out there:

http://www.apache.org/dist/httpd/modpython/win/3.2.8/


On Tue, 21 Feb 2006, Nicolas Lehuen wrote:


Hi Grisha,

Could you also put the Win32 binaries and make sure they are
referenced on the download page ? We regularly have questions about
where those binaries are, and I end up serving the files from my
personal hosting solution, which is not really tailored for that.

You can find the binaries here :

http://nicolas.lehuen.com/download/mod_python

TIA and regards,
Nicolas

2006/2/21, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:


Resolved, the files have been placed on www.apache.org/dist, allowing time
for mirror sync, then the web page update, then an announcement.

Grisha

On Mon, 20 Feb 2006, Graham Dumpleton wrote:


+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 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 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows
2000 SP4
  +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows

XP SP2


Barry Pederson <[EMAIL PROTECTED]>
  +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2

Jim Gallacher <[EMAIL PROTECTED]>
  +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5

Re: Constructing of a URL for location redirect.

[Gregory (Grisha) Trubetskoy]

On Thu, 16 Feb 2006, Nick wrote:


Nicolas Lehuen wrote:

BTW, did we ever considered using SWIG to map the Apache API ? I know
it can be quite tricky to use, but it could be a real time saver.


That's essentially what mod_snake did, and why I liked it so much.  Though I
don't remember if it used swig or pyrex.


It used SWIG. I'm -1 on using SWIG, I like the hand-crafted quality of 
mod_python.


SWIG in my opinion is good when you want some kind of an API made 
available to you quickly, but in a static environment where can put some 
thought into functionality, usability, Pythonic-ness of every approach, 
write documentation with good examples and a meaningful test case SWIG 
does not buy much.


If someone just wanted to map the APR to Python - they can always use 
SWIG, but that's not what mod_python is about.


Grisha

[SECURITY] A Security Issue with FileSession in 3.2.7

[Gregory (Grisha) Trubetskoy]

If you are using the recently released mod_python 3.2.7 please beware that a 
security issue was discovered in the FileSession code.


You are vulnerable only if you are using mod_python 3.2.7 AND you are using 
FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled by 
default, therefore if you are using mod_python Session in its default 
configuration you are not vulnerable.


The extent of this vulnerability is limited. Only a user who already has an 
account (or some ability to write to the filesystem) on the system running 
httpd could exploit it, and to the best of our knowledge such a user could 
potentially cause httpd to execute arbitrary code.


We are working on a security release of the next version of mod_python and 
expect it to be out shortly. Until then, please do not use FileSession.


Regards,

Your mod_python team.

Re: Getting Started on mod_python 3.3.

[Gregory (Grisha) Trubetskoy]

On Tue, 14 Feb 2006, Nicolas Lehuen wrote:


2006/2/14, Graham Dumpleton <[EMAIL PROTECTED]>:
[...]

If we want to go down the path of having interim 3.2 bug rollup releases
while 3.3 is being developed, might I suggest that we target the following
for such a release in the near future.

MODPYTHON-77

  The Simplified GIL Aquisition patches.


If this is the one where you get "Restriction Execution" errors upon 
launching a thread, then I'm kinda keen on seeing this fixed sooner than 
later. Just my $0.02. :-)



Grisha

Re: mutex dir?

[Gregory (Grisha) Trubetskoy]

On Tue, 14 Feb 2006, Jim Gallacher wrote:

I wonder if we should generalize this, so rather than PythonMutexDir, we have 
PythonModuleConfig. Usage might look like:


PythonModuleConfig mutex_dir /path/to/mutexs
PythonModuleConfig max_mutex_locks 8


I may be wrong, but I think the reason this was never configurable was 
because the mutex is created before the apache config is read.


Grisha

Re: Cool feature from mod_perl : Configure Apache with Perl

[Gregory (Grisha) Trubetskoy]

This has been discussed before, and I think it came down to that it wasn't 
clear how this is any better than simply generating your httpd.conf with 
an outside Python script.


I think some other arguments were that this changes the syntax of the 
config file very radically and therefore this isn't the right idea 
(regardless of the language) and also the Python indentation becomes an 
issue to deal with.


Grisha

On Mon, 13 Feb 2006, Nicolas Lehuen wrote:


Hi,

I'm currently reading the feature section from mod_perl. Initially, I
was trying to find information about how they cope with
multithreading, multiple interpreter instantiation and code reloading,
but I stumbled upon this :

http://perl.apache.org/start/tips/config.html

Now, I can't stand Perl, but this feature is quite cool, isn't it ?
Would it be difficult to implement, say, in mod_python 4.0 ?

Regards,
Nicolas

Re: For the curious : how mod_perl handles threading

[Gregory (Grisha) Trubetskoy]

On Mon, 13 Feb 2006, Nicolas Lehuen wrote:


http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support


Which part of it - the pool of interpreters? Are they doing it out of 
necessity, i.e. there is no way to run multiple threads in Perl like we do 
in Python because of Python's GIL?


Grisha

ANNOUNCE: Mod_python 3.2.7

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.7 release of mod_python. Mod_python 3.2.7
is considered a stable release, suitable for production use.

Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within the server. With mod_python you can write
web-based applications in Python that will run many times faster than
traditional CGI and will have access to advanced features such as
ability to maintain objects between requests, access to httpd
internals, content filters and connection handlers.

The 3.2.7 release has many new features, feature enhancements, fixed
bugs and other improvements over the previous version. See Appendix A
of mod_python documentation for more details.

Mod_python 3.2.7 is released under Apache License version 2.0.

Mod_python 3.2.7 is available for download from:

http://httpd.apache.org/modules/python-download.cgi

More information about mod_python is available at:

http://httpd.apache.org/modules/

Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and
everyone else who contributed to and helped test this release, without
your help it would not be possible!

Regards,

Grisha Trubetskoy

Re: 3.2.7 is will not work with apache 2.2

[Gregory (Grisha) Trubetskoy]

On Sat, 11 Feb 2006, Jim Gallacher wrote:

The download page under the "Apache Mod_python 3.2.7 is now available" 
heading states:


   "It will also work with HTTP Server 2.2, but this support should be 
considered experimental at this point."


This is not correct.


fixed

Grisha

Re: site.

[Gregory (Grisha) Trubetskoy]

On Fri, 10 Feb 2006, Daniel J. Popowich wrote:

Could we run mod_python on apache.org's site, like, say, the current 
version?  ;-)


We could ask again, but last time the answer was no, and I tend to agree. 
But I also understand that we have Solaris servers on which zones can be 
created where we could run our own httpd.


But it always comes back to the same point - running a nice website takes 
a lot of time and effort (possibly more than it takes to actually develop 
mod_python), and until there is someone ready to create and maintain 
content and run the site and the code on it, there is no point in going 
there.


Grisha

Re: [DRAFT] ANNOUNCE: Mod_python 3.2.7

[Gregory (Grisha) Trubetskoy]

On Thu, 9 Feb 2006, Jim Gallacher wrote:

Depending on Grisha's preference, I think we should either put the 
content in svn and have a cron job on modpython.org do a nightly update, 
or start using the Apache infrastructure for the website. See 
http://www.apache.org/dev/project-site.html for more info.


We've been talking about moving modpython.org to apache infrastructure for 
years, it's just always ended up being a lower priority thing that never 
got done. modpython.org isn't much of a site at this point, but if someone 
would be willing to step up and dedicate some serious time to web design 
and content, perhaps it would make it worth it to actually do the work of 
moving it...


Grisha

3.2.x branch

[Gregory (Grisha) Trubetskoy]

On Thu, 9 Feb 2006, Jim Gallacher wrote:

Looks good. As soon as you make the official announcement I'll create 
branches/3.2.x in svn and we can start on 3.3.


I don't think we need to wait for the announcement - 3.2.7 is already out 
if you look on the download page, the announcement is more about 
"marketing" if you will.


Grisha

[DRAFT] ANNOUNCE: Mod_python 3.2.7

[Gregory (Grisha) Trubetskoy]

Here is the announcement draft - if you see anything that needs changing, 
let me know, otherwise i'll send it out in a couple of days.



From: "Gregory (Grisha) Trubetskoy" <[EMAIL PROTECTED]>
To: announce@httpd.apache.org, [EMAIL PROTECTED]
Cc: python-dev@httpd.apache.org
Newsgroups: comp.lang.python
Subject: ANNOUNCE: Mod_python 3.2.7

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.7 release of mod_python. Mod_python 3.2.7 is
considered a stable release, suitable for production use.

Mod_python is an Apache HTTP Server module that embeds the Python language
interpreter within the server. With mod_python you can write web-based
applications in Python that will run many times faster than traditional
CGI and will have access to advanced features such as ability to maintain
objects between requests, access to httpd internals, content filters and
connection handlers.

The 3.2.7 release has many new features, feature enhancements, fixed bugs 
and other improvements over the previous version. See Appendix A of 
mod_python documentation for more details.


Mod_python 3.2.7 is released under the new Apache License version 2.0.

Mod_python 3.2.7 is available for download from:

http://httpd.apache.org/modules/python-download.cgi

More infromation about mod_python is available at:

http://httpd.apache.org/modules/

Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and 
everyone else who contributed to and helped test this release, without 
your help it would not be possible!


Regards,

Grisha Trubetskoy

Re: mod_python 3.2.7 available for testing

[Gregory (Grisha) Trubetskoy]

On Tue, 7 Feb 2006, Graham Dumpleton wrote:


I'll also say +1 as core group vote. This means all 4 have voted
as +1 and no need to wait 72 hours now to see if I would veto it.


OK, I stuck the file on apache.org/dist for mirrors to pick it up. Next 
step is the download page change, then the announcement.


Nicolas - do we have a win32 file as well?

Grisha

Re: mod_python 3.2.7 available for testing

[Gregory (Grisha) Trubetskoy]

On Tue, 7 Feb 2006, Jim Gallacher wrote:

I assumed we would have a separate thread for the core vote, but what the 
heck. :)


+1 is my core vote.


+1 from me as well.

Grisha

Re: mod_python 3.2.7 available for testing

[Gregory (Grisha) Trubetskoy]

I think we have enough +1's. (If someone could tally them up in a single 
e-mail, that'd be great.) Should we start a core-group vote, or wait some 
more? On the bash issue - I think we can leave it as is, the affected 
distros will just have to maintain a patch in their build systems.


Grisha

Re: Hooking handler with ap_hook_map_to_storage().

[Gregory (Grisha) Trubetskoy]

On Tue, 7 Feb 2006, Graham Dumpleton wrote:


/* [2 1/2] map filename to storage */
ap_hook_map_to_storage(PythonStorageHandler,
   NULL, NULL, APR_HOOK_MIDDLE);


The function name doesn't ring a bell, so I probably was not aware of it. 
Could this be something more recent than the last release of mod_python? 
In any event - sounds like an interesting idea.


Grisha

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

I'd give a conditional +1 - I think it'd be good to sort out why previous 
releases passed on FreeBSD and this one does not. Perhaps people who ran 
FreeBSD tests could try an earlier mod_python version test to see if it 
too fails?


Grisha

On Tue, 31 Jan 2006, Jim Gallacher wrote:


Good enough for me. Shall we vote? If so I am:

+1

Jim

Graham Dumpleton wrote:

I am having problems with posts to python-dev mailing list from home
occassionally disappearing in a black hole. Thus my post on this topic
before Jim brought it up in the first place vanished. What I has said was:



this code runs smoothly, i.e. no segfaults, all tests passed:
FreeBSD 4.9:

 Apache/2.0.50 (prefork) Python/2.3.4
 Apache/2.0.55 (prefork) Python/2.4.2


Okay, this is good.

If there is a general consensus that this is a reasonable solution,
the question is what should be done with 3.2.6. Should it be released
with this   problem in it and fix it later in 3.3?

Personally, I really don't think that connection handlers in
mod_python get used by anyone and so don't see a pressing need to go
fixing it right   now. Thus I would say go with 3.2.6 as final with how
it is.

Is there anything else of concern that is holding us up now on an
official release of 3.2.6?



In other words, I agree with Nicolas, we should just release it. If 
someone

actually came up and said they were using connection handlers for
something significant, then I might change this view, but I doubt anyone
is using them.

I would also point out that JIRA lists lots of other issues, some of them
minor and trivial to fix but which would be more worthwhile than fixing
than this connection handler issue. We have already said we will defer
these in the interest of getting a final version of 3.2 out sooner rather
than later.

Thus, as much as I would prefer to see as much as possible fixed, I
think we just have defer further changes to next version.

Graham

Jim Gallacher wrote ..


Nicolas Lehuen wrote:


OK, so shall we schedule the 3.2.x release for 2007, then ?

As for the Apache 2.2 version, what if we roll in your suggested
patch, Jim, then discover a bunch of problem related to it during the
beta tests ? Will we wait until they are all fixed to release the 3.2
version ? Apache 2.2 is quite new so we'll likely to have to squish
bugs, due for example to new interaction between Apache filters and
mod_python. That's a wild guess but filters have been modified in
Apache 2.2 so I'm sure something evil lurks there.


I'm totally happy to defer changes for Apache 2.2 as I don't personally
plan on migrating any time soon. The only reason I brought it up is that
some of the code which seems to be causing issues for Apache 2.2 happens
to reside in connobject.c, which is an area of interest for the 
_conn_read issue. Even if we were to roll fixes for apache 2.2 into mp

3.2, I'm not suggesting we advertise apache 2.2 compatibility just yet.




Or we could simply forget about making the release one day and
tell every user to use the latest snapshot from subversion. Sorry to
be like that, but we have users out there that would be perfectly
happy with the current state of the 3.2.6 version, and a lot of our
answers on the mailing list are "yup, we know this bug, it's already
been fixed one year ago, but don't worry, you'll get the bugfix soon
enough".


Point taken, and it is a very good point indeed.



Once again, it seems that no regression have been introduced in 3.2.6
vs 3.1.4, so we should release it ASAP and try to keep a steady
release rythm afterwards. When we'll get momentum we'll solve a bunch
of problem pretty fast, but it's been a year now that we are paralysed
by perfectionism. What could be worse than leaving our users out there
with the current 3.1.4 version ?


I *still* wonder why the whole ConnectionHandler issue was not seen on
FreeBSD with mp 3.1.4 though. I'll need to check the svn logs again but
I'm pretty sure this is not a new unit test.

That being said I'm not personally concerned about this issue since it
doesn't affect every platform (or more selfishly I should say it doesn't
affect the OS I'm working on) and I suspect that not many people are 
directly interacting with the connection object.


What's that old line about open source software... Release early, 
release often?


Jim



2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>:



I assume we will be doing a 3.2.7 release if Graham's fix for the
ConnectionHandler / MODPYTHON-102 problem works?

If that is the case I wonder if we should roll in the changes to 
support

apache 2.2. I scanned mod_python for deprecated or removed apr calls


and


can find only one (apr_sockaddr_port_get), plus the missing
APR_STATUS_IS_SUCCESS macro.

The original macro is:

#define APR_STATUS_IS_SUCCESS(s)   ((s) == APR_SUCCESS \
   || (s) == APR_OS_START_SYSERR + NO_ERROR)


The discussion on httpd-dev suggested that this macro should be
substituted with a simple test such as "if (rc != APR_

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

On Tue, 31 Jan 2006, Jim Gallacher wrote:

I assume we will be doing a 3.2.7 release if Graham's fix for the 
ConnectionHandler / MODPYTHON-102 problem works?


Unfortunately, the answer is yes... As much as we'd like to release it 
sooner, I think it's important to not loose the perspective that quality 
over speed is what we favor. In other words - if it takes a little longer 
to get the quality we want, then that's just fine. :-)


Grisha

Re: Segfaults in ConnectionHander

[Gregory (Grisha) Trubetskoy]

This may be a good question to post to dev@httpd.apache.org

Grisha

On Mon, 30 Jan 2006, Graham Dumpleton wrote:


Getting a bit closer now, have next part of puzzle worked out.

Graham Dumpleton wrote ..

This is starting to look really ugly.

In _conn_read(), it first creates a bucket brigade from the connection
objects pool object. No chance of this being destroyed prematurely
as a result.

bb = apr_brigade_create(c->pool, c->bucket_alloc);


From what I understand, it then makes a call which links the bucket

brigade to the actual source of data.

rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);

Under normal circumstances this would also have the side effect of
performing the first actual read of data off the socket connection which
the client created to Apache.


When ap_get_brigade() is called, it is actually calling through to the
function core_input_filter() in Apache (server/core.c). In that function, it
ultimately hits the code:

   e = APR_BRIGADE_FIRST(ctx->b);
   rv = apr_bucket_read(e, &str, &len, block);

   if (APR_STATUS_IS_EAGAIN(rv)) {
   return APR_SUCCESS;
   }

Tracking down into apr_bucket_read() it ends up calling the function
socket_bucket_read() containg the code:

   *str = NULL;
   *len = APR_BUCKET_BUFF_SIZE;
   buf = apr_bucket_alloc(*len, a->list); /* XXX: check for failure? */

   rv = apr_socket_recv(p, buf, len);

   if (block == APR_NONBLOCK_READ) {
   apr_socket_timeout_set(p, timeout);
   }

   if (rv != APR_SUCCESS && rv != APR_EOF) {
   apr_bucket_free(buf);
   return rv;
   }

The apr_socket_recv() is what is doing the initial read of data from the
socket connection. This should block until the first data is received.

What is happening though is that it is returning -1 with errno set to
EAGAIN. Thus it frees the temporary bucket it created and returns
EAGAIN as the result.

If you note the code in the core_input_filter() it has:

   if (APR_STATUS_IS_EAGAIN(rv)) {
   return APR_SUCCESS;
   }

Thus, when EAGAIN is encountered, it simply returns success and does
not do anything else.

Returning back up to _conn_read() in mod_python source code, we have
where core_input_filter() was called ap_get_brigade():

   Py_BEGIN_ALLOW_THREADS;
   rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
   Py_END_ALLOW_THREADS;

   if (! APR_STATUS_IS_SUCCESS(rc)) {
   PyErr_SetObject(PyExc_IOError,
   PyString_FromString("Connection read error"));
   return NULL;
   }

Since APR_SUCCESS was returned and assigned to "rc", no problem is detected.

The code which follows then assumes that the first bucket in the bucket
brigade actually contains valid data, when in fact the first bucket is actually
crap as nothing was done to set up a valid bucket since EAGAIN was returned.
As a consequence it crashes.

Thus in summary, _conn_read() doesn't cater in any way for the possibility
that the initial socket read may have failed because of EAGAIN and thus
the bucket is bogus. The problem is, how is it mean't to know this if the
value APR_SUCCESS is returned by ap_get_brigade().

At this point, seems a bit of research is needed of other examples of
connection handlers for Apache to see how they handle the initial startup
sequence and processing of initial data. What is in mod_python now does
not appear to be reliable in the face of an EAGAIN error occuring.

Graham

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

On Sun, 29 Jan 2006, Graham Dumpleton wrote:


 buffer += bufsize;



On a second thought - yes, you're right :-)

Grisha

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

On Sun, 29 Jan 2006, Graham Dumpleton wrote:


Grisha wrote ..


 buffer = bufsize;



I suspect you mean't:

buffer += bufsize;


buffer = bufsize should be correct because you move the pointer to the end 
of where the bufer was. buffer += bufsize would set it further than you 
need it.



Anyway, this change doesn't help with Mac OS X as it doesn't even get invoked.

Unlike suggestions by someone else that "self" seemed to be getting corrupted,
it looks fine to me, and code simply crashed down in:

 apr_bucket_read(b, &data, &size, APR_BLOCK_READ)

on very first call to it. Thus need to start tracking into Apache itself and 
see what
there may be about bucket structures that isn't correct. This is where I got to
last time before I gave up, feeling it wasn't worth the effort at the time. 
I'll try
and build a version of Apache with debug so I can get a better stack trace.


The first thing I'd check is for validity of b. Buckets use reference 
counting much like Python, so sometimes it's possible for a bucket to 
"self-distruct".


Grisha

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

On Sun, 29 Jan 2006, Jim Gallacher wrote:

I don't know if this is the answer to the problem, but it looks like a bug 
anyway. In connobject.c starting at line 133:


   /* time to grow destination string? */
   if (len == 0 && bytes_read == bufsize) {

   _PyString_Resize(&result, bufsize + HUGE_STRING_LEN);
   buffer = PyString_AS_STRING((PyStringObject *) result);
   buffer += HUGE_STRING_LEN;
   bufsize += HUGE_STRING_LEN;
   }


It looks like we've just set the buffer pointer to an address somewhere 
inside the buffer. That can't be good. The buffer pointer should be set to 
the bytes_read position.


...or bufsize. Of course they are the same, but I think this would read 
cleaner:


if (len == 0 && bytes_read == bufsize) {

_PyString_Resize(&result, bufsize + HUGE_STRING_LEN);
buffer = PyString_AS_STRING((PyStringObject *) result);
buffer = bufsize;
bufsize += HUGE_STRING_LEN;
}

This bug would garble the data if it's at least twice HUGE_STRING_LEN, 
since the first time around the code would work OK because bufsize would 
equal HUGE_STRING_LEN.


Grisha

Re: 3.2.6 test period - how long do we wait?

[Gregory (Grisha) Trubetskoy]

On Thu, 26 Jan 2006, Jim Gallacher wrote:


It seems like any 3.2.6 testing that is going to be done, has been done.


I've been kinda swamped with unrelated things past two weeks, so I wasn't 
paying much attention. Perhaps an e-mail summarizing the +1's so far and a 
quick vote of the core group on whether this is enough?


Grisha

Re: please set up a mod_python core group

[Gregory (Grisha) Trubetskoy]

On Thu, 19 Jan 2006, Jorey Bump wrote:

+1 here, but since the build process and typical MPM differs among platforms, 
could we see a list that this group represents?


This group would not represent any platforms when acting in _this_ 
capacity. One of the group's responsibility would be to decide whether 
sufficient number of platforms were represented by tests done by anyone on 
this mailing list (including anyone from this group, of course).


Grisha

Re: please set up a mod_python core group

[Gregory (Grisha) Trubetskoy]

Thanks Roy. Very timely, since 3.2.6 is (so far) going to be a 
final/stable release.


I propose that for starters those people are:

me (I'm also in the Apache HTTP Server PMC)
Jim Gallacher
Nicolas Lehuen
Graham Dumpleton

Just to clarify this a bit - I think a +1 on successful test for a 
particular OS/whatever combination from any of the above people is NOT the 
same as the "binding +1" Roy's referring to. So when we're done collecting 
+1's which are just test results from subscribers of the list (and any 
subscriber can send a +1), then at least 3 of the above list need to agree 
that we have sufficient approval to go ahead with the release.


Roy - could you confirm this makes sense?

Grisha


On Wed, 18 Jan 2006, Roy T. Fielding wrote:


It looks like mod_python is making good progress and everyone
is collaborating in the Apache way of testing and voting.
That's great!

Unfortunately, I have almost no insight into who these great people
are that are doing the RM task and testing and voting and preparing
for a next release.  That's not so great, since it is my job (as
VP of Apache HTTP Server Project) to be sure that the ASF knows all
this work is being done in its name and so that all of the people
doing it are appropriately recognized for their work.

So, please, take a few moments to decide amongst yourselves who
should have binding votes on mod_python (i.e., who has earned it),
keeping in mind that you need at least three binding +1 votes in
order to make any release at Apache, and send me a list of names
and email addresses of those people so that I can properly
record them in our records.

Cheers,

Roy T. Fielding
for the Apache HTTP Server PMC

Re: [jira] Created: (MODPYTHON-107) mod_python.publisher shouldn't flush result when written.

[Gregory (Grisha) Trubetskoy]

On Wed, 4 Jan 2006, Graham Dumpleton (JIRA) wrote:

This makes one wander if there should be a configurable option for 
mod_python.psp to tell it not to flush output as well so that 
CONTENT_LENGTH could be used in that case as well. ???


I kinda mentioned this in the previous e-mail - PSP always does not flush 
output, in fact that 0/1 argument was added to req.write() just for PSP. 
So for pure PSP pages, content-length _should_ work (haven't tested it).


Grisha

Re: [jira] Created: (MODPYTHON-105) mod_python.publisher should notdiscard content for HEAD request.

[Gregory (Grisha) Trubetskoy]

On Wed, 4 Jan 2006, Graham Dumpleton wrote:


Either way, we agree that mod_python.publisher should still output
content for HEAD.


Yep.


I would also propose as a change that the req.write() call not cause
output to be flushed to allow an output filter like CONTENT_LENGTH
to be used.


Hmmm... This needs some more research. i.e. I don't quite completely 
understand why the CONTENT_LENGTH filter can only count bytes when there 
is no flush() (shortcoming of CONTENT_LENGTH or an impossibility?)...


Implicit buffering would be a significant change - if someone used 
req.write() to generate "dynamic" content (e.g. output from one of those 
traceroute sites being sent in real time), they'd be very surprised to not 
see the output anymore. CGI I think flushes implicitely at every end of 
line which where this behaviour comes from...


On the other hand implicit flush slows things down tremenduosly when you 
have lots of req.write()s, this was discovered when PSP was added and 
that's when the no-flush argument was introduced, so if backwards 
compatibility was of no concern, I'd make implicit buffering (i.e. 
no-flush) default.



I'll add a new JIRA issue for that.


Yep, totally.

And thanks for all your help BTW :-)

Grisha

Re: [jira] Created: (MODPYTHON-105) mod_python.publisher should not discard content for HEAD request.

[Gregory (Grisha) Trubetskoy]

On Wed, 4 Jan 2006, Gregory (Grisha) Trubetskoy wrote:

It may be a good idea to check the httpd-dev archives to see if the 
issue of HEAD has been discussed in the past.


Here's a relevant bit of info from the httpd-dev archives:


* All handlers should always send content down even if r->header_only
  is set.  If not, it means that the HEAD requests don't generate the
  same headers as a GET which is wrong.


Grisha

Re: [jira] Created: (MODPYTHON-105) mod_python.publisher should not discard content for HEAD request.

[Gregory (Grisha) Trubetskoy]

On Mon, 2 Jan 2006, Graham Dumpleton (JIRA) wrote:


In addressing MODPYTHON-71, mod_python.publisher code was changed to read:

   if req.method!='HEAD':
   req.write(result)

This change should not really have been made and it should be changed 
back to what was there before, ie., just:


   req.write(result)


[...]

As an an example of an Apache module that uses output filters to do 
stuff, there is mod_cache. Luckily in that case, a HEAD request is one 
of various cases where mod_cache decides it will not use the output. 
This does not mean though that some other output filter that someone is 
using might expect content to be there for HEAD.


I am not sure I agree with this explanation (while I do agree that the 
behaviour should be reverted, but for different reason, see below). The 
RFC is pretty clear on HEAD: "The HEAD method is identical to GET except 
that the server MUST NOT return a message-body in the response.", so for a 
filter (or anything) to expect the content with HEAD is wrong.


In summary, one could also say that if a user wants to not output 
anything for a HEAD request, that is there decision, but 
mod_python.publisher should not be making that decision for them.


May be not for the publisher, but given the "MUST NOT" it should be OK for 
either httpd or mod_python to do this. If httpd does not do it, then 
perhaps it should be made part of req.write()? It may be a good idea to 
check the httpd-dev archives to see if the issue of HEAD has been 
discussed in the past.


In any event, I think the behaviour should be reverted to ignore HEAD for 
now simply because it is a half-ass solution given that req.write() gets 
through, especially because PSP templates rely on req.write() primarily.


I think for 3.2 we can just leave it at that, but for 3.3 to seriously 
consider whether mod_python should chop output for HEAD requests.


Also, I think a link to this JIRA issue as a comment somewhere in the code 
would be great or someone down the road will repeat this whole HEAD thing 
again.


Grisha

Re: [jira] Updated: (MODPYTHON-106) PythonAutoReload directive can't be turned off in config.

[Gregory (Grisha) Trubetskoy]

On Mon, 2 Jan 2006, Graham Dumpleton (JIRA) wrote:


Should this be fixed in 3.2, given that it probably hasn't work in 3.0 and 3.1?


I think it would be a good idea. Hopefully this is the last fix before we 
roll it out.


Grisha

3.2.6b

[Gregory (Grisha) Trubetskoy]

I hope everyone's having a merry Christmas or whatever other holidays 
you're celebrating :-)


I haven't been following the list very closely lately, but it looks like 
last time 3.2.6b was brought up a bunch of bugs came out of the woodwork.


Does it look like we're near being ready to roll 3.2.6b now?

Grisha

Re: input/output filters and .htaccess

[Gregory (Grisha) Trubetskoy]

On Wed, 21 Dec 2005, Graham Dumpleton wrote:


/* register the filter NOTE - this only works so long as the
   directive is only allowed in the main config. For .htaccess we
   would have to make sure not to duplicate this */

Having input/output filters be able to be specified in .htaccess
must have been considered, but there must have been some issue
with it that prevented it being done at the time.


Hmmm, looks like it will not be able to be done after all. This is
because registration of a filter by name is done at server scope.
Thus, if done from a .htaccess file in one directory, it will then
be visible in other scopes. The continual registration of the
filter each time a request hits that directory will also cause a
growing use of memory from the server pool (I think). Pity.


This may be something you could clarify on the httpd-devel or apr-devel 
lists, may be we're missing something in how it was intended to work.


Grisha

Re: input/output filters and .htaccess

[Gregory (Grisha) Trubetskoy]

On Tue, 20 Dec 2005, Graham Dumpleton wrote:


Grisha, do you remember why the following warning is present in
directive_PythonInputFilter() and directive_PythonOutputFilter() of
"mod_python.c".

   /* register the filter NOTE - this only works so long as the
  directive is only allowed in the main config. For .htaccess we
  would have to make sure not to duplicate this */

Having input/output filters be able to be specified in .htaccess
must have been considered, but there must have been some issue
with it that prevented it being done at the time.


I think it was because if specified in .htaccess, that code would be 
executed for every request and something would need to be done to make 
sure ap_register_input_filter() is only called once. I don't remember the 
intricate details at this point, and it's possible that this warning is 
unnecessary either because I didn't understand something or perhaps the 
way Apache works has changed. In any event, I'd do some careful 
investigating before disregarding that NOTE :)


Grisha

Re: input/output filters and .htaccess

[Gregory (Grisha) Trubetskoy]

This sounds like a good idea, but it's probably better to push this off to 
3.3 just to veer on the side of caution.


My $0.02

Grisha

On Tue, 20 Dec 2005, Graham Dumpleton wrote:


Anyone know if there are any technical reasons why input/output filters
as they exist at the moment, applying only to body content and not
headers, can not be specified in a .htaccess files?

Specifically, the SetInputFilter, SetOutputFilter, AddInputFilter and
AddOutputFilter directives of Apache can be specified in either main
server configuration or .htaccess files, yet the PythonInputFilter and
PythonOutputFilter directives are only allowed to be specified in the
main server configuration.

This is because mod_python.c contains:

   AP_INIT_TAKE12(
   "PythonInputFilter", directive_PythonInputFilter, NULL, 
RSRC_CONF|ACCESS_CONF,

   "Python input filter."),
   AP_INIT_TAKE12(
   "PythonOutputFilter", directive_PythonOutputFilter, NULL, 
RSRC_CONF|ACCESS_CONF,

   "Python output filter."),

If however I change it to:

   AP_INIT_TAKE12(
   "PythonInputFilter", directive_PythonInputFilter, NULL, OR_ALL,
   "Python input filter."),
   AP_INIT_TAKE12(
   "PythonOutputFilter", directive_PythonOutputFilter, NULL, OR_ALL,
   "Python output filter."),

it is then possible to use the mod_python directives in a .htaccess file.

Running the code this way appears to work for both input and output filters
when specified in the .htaccess file without problems.

So, does anyone know why this might be a bad idea? I can't really think of
any reasons why it shouldn't be okay. If there is some confirmation that
it all sounds reasonable, I'll create a JIRA issue for it to be a future
enhancement.

Graham

Re: Does 3.2 still support python 2.2?

[Gregory (Grisha) Trubetskoy]

On Fri, 9 Dec 2005, Jim Gallacher wrote:

Next question. Should we bump the Apache version requirement as well. 
Currently the docs state that Apache 2.0.40 or later is required. I 
don't recall seeing anyone testing mod_python 3.2 on anything less than 
apache 2.0.53. I don't know if there are any changes between 40 and 53 
that may have a negative impact, but if we haven't actually tested on 
the earlier versions are we just asking for trouble?


Probably :)

I don't remember where the 2.0.40 came from. There may have been a 
technical reason for it, or may be it was just the current version at the 
time. I think the most honest thing to would be to say that we've tested 
it with 2.0.53, but it will most likely work with a few minor versions 
earlier just as well. Since we're part of HTTP project, we should anyhow 
encourage folks to use the most recent versions.


Grisha

Re: [jira] Created: (MODPYTHON-97) mod_python.publisher iterablesand content_type broken

[Gregory (Grisha) Trubetskoy]

On Fri, 9 Dec 2005, Nicolas Lehuen wrote:

I quite agree now that mod_python 3.2 should be a big bugfix release, 
instead of a release with a lot of new bells and whistles. Let's comment 
this thing out and see if we bring it back later.


Sounds good. I'm undecided on whether special tratment of generators by 
the publisher is a good idea (who know perhaps there is some neat paradigm 
of generator-generated content?), but we can leave this off for 3.3. And 
if we do decide to go that route it could probably be implemented in a 
finer way, i.e. so that not any iterable is treated this way, but only 
actual generators.


Grisha

Re: [jira] Created: (MODPYTHON-97) mod_python.publisher iterables and content_type broken

[Gregory (Grisha) Trubetskoy]

On Thu, 8 Dec 2005, Gregory (Grisha) Trubetskoy wrote:


 def index(req)
 req.content_type = 'text/plain'
 yield '1\n'
 yield '2\n'
 yield '3\n'
 yield '4\n'

 When published, this module should return a text content with
'1\n2\n3\n4\n'.

---

I'd expect this to return '1\n'. Because in my mind one HTTP request 
corresponds to one call to the published function?


Actually, I take that back. It should return something more along the 
lines of ''.


Does this make sense?

Grisha

Re: [jira] Created: (MODPYTHON-97) mod_python.publisher iterables and content_type broken

[Gregory (Grisha) Trubetskoy]

On Thu, 8 Dec 2005, Jim Gallacher wrote:


I believe this is the source of this change:
http://issues.apache.org/jira/browse/MODPYTHON-15


Thanks! So quoting from the description:

---

  Suppose this function in a published module :

  def index(req)
  req.content_type = 'text/plain'
  yield '1\n'
  yield '2\n'
  yield '3\n'
  yield '4\n'

  When published, this module should return a text content with
 '1\n2\n3\n4\n'.

---

I'd expect this to return '1\n'. Because in my mind one HTTP request 
corresponds to one call to the published function?


(Also I guess a subsequent call which happens to hit the same httpd 
process would return '2\n', etc.)


Grisha

Re: [jira] Created: (MODPYTHON-97) mod_python.publisher iterables and content_type broken

[Gregory (Grisha) Trubetskoy]

On Thu, 8 Dec 2005, Graham Dumpleton (JIRA) wrote:

In 3.2, mod_python.publisher was modified so that if it encountered an 
interable it would recursively iterate over the items and publish each 
with the result being concatenated.


I didn't know this either. I'm curious what the rational for this was - 
I'm not sure whether this is good or bad. If I have an object which it 
iterable, but also has its own idea of how to represent itself as a string 
as a whole, isn't this going to be slightly unexpected?


Grisha

Re: What's in a URL ?

[Gregory (Grisha) Trubetskoy]

On Mon, 5 Dec 2005, Nicolas Lehuen wrote:


Understood. Can I use the branches/nlehuen directory to store this kind of
work in progress ? I'm pretty used to use SVN as a backup policy...


Yes, that'd be much better, this way we avoid these things trickling into 
the final release tar file.


Grisha

Re: What's in a URL ?

[Gregory (Grisha) Trubetskoy]

On Sat, 3 Dec 2005, Nicolas Lehuen wrote:


2. I don't know - I did not made this to distribute


It's a _very_ nice document, but I think you jumped the gun by checking it 
into Doc because it's not a .tex file and doesn't fit into the Mod_python 
manual, which is what the Doc directory is for.


I worry we may develop a tendency towards treating the Apache SVN as file 
sharing mechanism, which is not what it's for. At least whatever is 
underneath mod_python/ directory in SVN must IMHO be part of the "final 
package", and should probably not include any 
scratch-pad/temoprary/work-in-progress type stuff.


Grisha

Re: Various musings about the request URL / URI / whatever

[Gregory (Grisha) Trubetskoy]

I guess the fundamental problem here now that I think about it is that 
such a Host header based determination relies on trusting the client of 
what the host should be, which, if you think about it isn't a good 
programming practice.


For example, if Apache is configured such that it just answers requests 
regardless of what the Host header says (which is the default 
configuration usually), then if the client sends "gobbledygook.bleh" as 
the host name, then that becomes the URL. While this may be harmless, it 
can at least be a source of confusion and there may be even a security 
issue lurking there somewhere.


I think a properly designed site should insist on its host name, i.e. "I 
see you think I'm gobbledygook.bleh, but I'm going to redirect you to 
http://www.modpython.org/ because that is my true name". This is very 
common with sites that respond to both www.site.com and site.com, but 
insist on only one of those by redirecting.


Grisha

Re: Various musings about the request URL / URI / whatever

[Gregory (Grisha) Trubetskoy]

On Tue, 29 Nov 2005, Jim Gallacher wrote:


Daniel J. Popowich wrote:


Here, here!!  I've wanted parsed_uri to work as expected for quite
some time...I'm actually in a position where I could devote some time
to tracking this down.  If apache doesn't provide it, I think
mod_python should at least fill it in, right? 


+1


I don't know what the specific issue is with parsed_uri, if this is a 
mod_python bug it should just be fixed BUT if this is an issue with httpd, 
I don't think we should cover the problem up by having mod_python "fix" 
it. Since we are part of the HTTP Server project, we should just fix it in 
httpd.


Grisha

Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency

[Gregory (Grisha) Trubetskoy]

On Tue, 29 Nov 2005, Jim Gallacher wrote:

I still think the correct place to create the index dictionary is in the 
__init__ phase. Using the dictionary-on-demand idea only improves performance 
on the second access to a form field. For the first access you are still 
iterating through the whole list for each field name.


I am still not convinced we need an index. I'd like to see some concrete 
proof that we're not engaging in "overoptimization" here - is this really 
a bottleneck for anyone?


If we're concerned (and I'm not at this point) that FieldStorage is too 
slow, we should just rewrite the whole thing in C :-)


Grisha

Re: Various musings about the request URL / URI / whatever

[Gregory (Grisha) Trubetskoy]

On Tue, 29 Nov 2005, Nicolas Lehuen wrote:


def current_url(req):


[snip]



   # host
   current_url.append(req.hostname)


[snip]

This part isn't going to work reliably if you are not using virtual hosts 
and just bind to an IP number. Deciphering the URL is an impossible task - 
I used to have similar code in my apllications, but lately I realized that 
it does not work reliably and it is much simpler to just treat it as a 
configuration item...



First question, is there a simpler way to do this ? Ironically, when using
mod_rewrite, you get an environment variable named SCRIPT_URI which is
precisely what I need (SCRIPT_URL, also added by mod_rewrite, is equivalent
to req.uri... Don't ask we why). But relying on it isn't safe since
mod_rewrite isn't always used.


well - here's how it does it.

/*
 *  create the SCRIPT_URI variable for the env
 */

/* add the canonical URI of this URL */
thisserver = ap_get_server_name(r);
port = ap_get_server_port(r);
if (ap_is_default_port(port, r)) {
thisport = "";
}
else {
apr_snprintf(buf, sizeof(buf), ":%u", port);
thisport = buf;
}
thisurl = apr_table_get(r->subprocess_env, ENVVAR_SCRIPT_URL);

/* set the variable */
var = apr_pstrcat(r->pool, ap_http_method(r), "://", thisserver, thisport,
 thisurl, NULL);
apr_table_setn(r->subprocess_env, ENVVAR_SCRIPT_URI, var);

/* if filename was not initially set,
 * we start with the requested URI
 */
if (r->filename == NULL) {
r->filename = apr_pstrdup(r->pool, r->uri);
rewritelog(r, 2, "init rewrite engine with requested uri %s",
   r->filename);
}


Second question, if there isn't any simpler way to do this, should we add it
to mod_python ? Either as a function like above in mod_python.util, or as a
member of the request object (named something like url to match the other
member named uri, but that's just teasing).


I don't know... Since the result is going to be half-baked... I think a 
more interesting and mod_python-ish thing to do would be to expose all the 
API's used in the above code (e.g. ap_get_server_name, ap_is_default_port, 
ap_http_method) FIRST, then think about this.



And third question (in pure Spanish inquisition style) : why is
req.parsed_uri returning me a tuple full of Nones except for the uri and
path_info part ?


This is an httpd question most likely...


Ah, fourth question : why are we (mod_python, mod_rewrite and the CGI
environment variables) using the terms "URI" and "URL" to distinguish
between a full, absolute resource path and a path relative to the server,
whereas the definition of URLs and URIs is very vague and nothing close to
this (http://www.w3.org/TR/uri-clarification/#contemporary) ? Shouldn't we
save our souls and a lot of saliva by choosing better names ?


No, we (mod_python) should just use the exact same name that httpd uses. 
If we come up better names, then it's just going to make it even more 
confusing.



OK, OK, fifth question : we made req.filename and other members writable.
But when those attributes are changed, as Graham noted a while ago, the
other dependent ones aren't, leading to inconsitencies (for example, if you
change req.filename, req.canonical_filename isn't changed). Should we try to
solve this


The solutions is to make req.canonical_filename writable too and document 
that if you change req.filename, you may consider changing 
canonical_filename as well and what will happen if you do not.



and provide clear definition of the various parts of a request
for mod_python 3.3 ?


Yes, that'd be good :)

Grisha

Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency

[Gregory (Grisha) Trubetskoy]

On Mon, 28 Nov 2005, Nicolas Lehuen wrote:


Why is the ordering so important ? I do understand we need to support
multiple values per field name, but I don't see why ordering is
needed.


I think that it may be dictated by some RFC (the stdlib does it this way 
too), I'm not sure, but it's a good question though, it'd be great to have 
it researched and answered so that we don't have to go over this point 
again.


Grisha

Re: [mod_python] ANNOUNCE: Mod_python 3.2.5 Beta

[Gregory (Grisha) Trubetskoy]

A couple of weeks perhaps? I don't think the final can happen before 
Apachecon without feeling rushed anyway, so we could target second half of 
December?


On Mon, 28 Nov 2005, Jim Gallacher wrote:


Grisha,

Speaking of 3.2.5 beta, how long do we wait before it becomes final?

Jim

Re: [SPAM] [mod_python] [SPAM] ANNOUNCE: Mod_python 3.2.5 Beta

[Gregory (Grisha) Trubetskoy]

I don't know how to do that, and it doesn't bother me that much :-)

Grisha

On Mon, 28 Nov 2005, David Fraser wrote:


Gregory (Grisha) Trubetskoy wrote:

The Apache Software Foundation and The Apache HTTP Server Project are 
pleased to announce the 3.2.5 Beta release mod_python.


Can we make sure the final release doesn't come out as SPAM on the announce 
list? :-)


David

Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency

[Gregory (Grisha) Trubetskoy]

Having looked at the FieldStorage code, I'm guessing the idea was that you 
parse fields as they come in and append them to a list. This preserves 
the original order of fields, in case it is needed.


I'm not sure that maintaining a dictionary alongside the list is the right 
thing to do. It might be, but there are some difficult questions to answer 
-e.g. how costly is a sequential search, and is the code complexity (and 
fieldstorage code is no picnic to read as it is) worth the speedup?


Also while it would speed up retrieval, it will slow down the "write" 
operation - when a field is added to fieldstorage you now need to append 
it to the list, AND check whether it exists in the dictionary, then add it 
there as well.


How often do developers access form fields via __getitem__?  I noticed the 
publisher does not use it - it iterates the list, so nothing would be 
gained there.


Also, something else to consider - is there a simple programatic solution 
that could be documented, e.g. something like


my_fs = util.FieldStorage(req)

dict_fs = {}
dict_fs.update(my_fs)

[have no idea whether this will work :-)]

and voila - you've got a dictionary based fieldstorage?

Anyway, just a few cents from me.

Grisha

Small docs gripe

[Gregory (Grisha) Trubetskoy]

In changes appendix:

http://www.modpython.org/live/mod_python-3.2.5b/doc-html/node97.html

it says: "Objects hierarchy a la CherryPy can now be published." I think 
it'd be better if it explained what this means without assuming that 
everyone knows what CherryPy does (I don't, for example)?


Grisha

ANNOUNCE: Mod_python 3.2.5 Beta

[Gregory (Grisha) Trubetskoy]

The Apache Software Foundation and The Apache HTTP Server Project are 
pleased to announce the 3.2.5 Beta release mod_python.


Version 3.2.5b of mod_python features several new functions and attributes 
providing better access to apache internals, file-based sessions and other 
session improvements, as well as many bug fixes and various performance 
and security improvements. A detailed description of the changes is 
available in Appendix A of the mod_python manual, also available here:


http://www.modpython.org/live/mod_python-3.2.5b/doc-html/node97.html

Beta releases are NOT considered stable and usually contain bugs.

This release is intended to solicit widespread testing of the code. We 
strongly recommend that you try out your existing applications and 
experiment with new features in a non-production environment using this 
version and report any problems you may encounter so that they can be 
addressed before the final release.


Preferred method of reporting problems is the mod_python user list 
[EMAIL PROTECTED]


Mod_python 3.2.5b is available for download from:

http://httpd.apache.org/modules/python-download.cgi

For more information about mod_python visit http://www.modpython.org/

Regards,

Grisha Trubetskoy and the Apache mod_python team.

Re: mod_python 3.2.5b available for testing

[Gregory (Grisha) Trubetskoy]

On Thu, 17 Nov 2005, Jim Gallacher wrote:


Gregory (Grisha) Trubetskoy wrote:


OK, I think we got enough +1's and no show-stopping problems (for a beta 
at least). I copied it over the apache server, once the mirrors sync I'll 
update the site and send the big announcement.


I was also thinking it was time for a wider release, but was hoping to see a 
+1 for FreeBSD 4 or 5 first.


+1

FreeBSD 4.9-RC
apache 2.0.53
Python 2.3

Grisha

Re: mod_python 3.2.5b available for testing

[Gregory (Grisha) Trubetskoy]

OK, I think we got enough +1's and no show-stopping problems (for a beta 
at least). I copied it over the apache server, once the mirrors sync I'll 
update the site and send the big announcement.


Grisha


On Mon, 14 Nov 2005, Jim Gallacher wrote:

A new mod_python 3.2.5 beta tarball is now available for testing. A windows 
binary should be available shortly.


This release is similar to 3.2.4b but fixes a couple of minor issues -
MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload).

Here are the rules:

In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to _this_
list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).

The files are (temporarily) available here:

http://www.modpython.org/dist/

Please download it, then do the usual

$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install

Then (as non-root user!)

$ cd test
$ python test.py

And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).

Thank you,
Jim Gallacher

Re: Developer Guidelines (was Re: More efficient FieldStorage, StringField and Field classes)

[Gregory (Grisha) Trubetskoy]

On Tue, 15 Nov 2005, Mike Looijmans wrote:


Then I get:

error: Python was built with version 7.1 of Visual Studio, and extensions 
need to be built with the same version of the compiler, but it isn't 
installed.


I don't have a VS license - that would mean I have to build my own Python in 
order to get any further. Oh dear...


I seem to remember long ago that if you find the code in distutils that 
produces this message and comment out that check, it still works even with 
incompatible VS's.


Grisha

Re: mod_python 3.2.5b available for testing

[Gregory (Grisha) Trubetskoy]

hehe - sorry about that, should be fixed now

Grisha

On Tue, 15 Nov 2005, David Fraser wrote:


Jim Gallacher wrote:

A new mod_python 3.2.5 beta tarball is now available for testing. A 
windows binary should be available shortly.


The windows binary for python 2.3 is borked, and contains its own md5sum, 
being only 68 bytes long.
This did raise the interesting thought of how easy it would be to create a 
file which contains its own md5sum, but aside from that, I think it should be 
reuploaded :-)


David

Re: board report for HTTP server project

[Gregory (Grisha) Trubetskoy]

On the mod_python side we got a 3.2.2 beta out and will try to get 3.2.? 
final done before Apachecon (hopefully). The last release (not counting 
security fix ones) was 20 months ago, so this is pretty significant.


Grisha

On Mon, 14 Nov 2005, Roy T. Fielding wrote:


Much to my surprise, I apparently have a board report due yesterday
for this Wednesday's board meeting.  Do we have any ASF issues that
need reporting to the board, aside from what is in STATUS*?
Any choice commentary?  Does anyone else feel like we have too many
dev lists for one project?

Roy

Re: [jira] Created: (MODPYTHON-87) psp_parser: replaces "\n" on \n

[Gregory (Grisha) Trubetskoy]

The culprit is this:

http://svn.apache.org/viewcvs.cgi/httpd/mod_python/trunk/src/psp_parser.l?rev=104353&r1=102649&r2=104353

Before the patch all the text would be enclosed in triple double-quotes 
(""") and all double-quotes within would be escaped. I guess Brendan 
O'Connor (who submitted the patch) thought putting an 'r' in front of the 
triple quotes would eliminate the need for escaping anything inside, but 
it ain't so. (In fact I seem to recall having gone that erroneous path 
myself originally).


To demonstrate:


print """blah\""""

blah"   <-- OK


print r"""blah""""

  File "", line 1
print r"""blah""""
 ^
SyntaxError: EOL while scanning single-quoted string

... and if we try to escape the quote:


print r"""blah\""""

blah\"  <-- BAD

... we don't get the original content. Therefore the "triple double-quote 
with double-quote escaped" is the only way to get consistency.


Thus the fix is to roll that patch entirely back because it's wrong.

This does NOT, however, address the issue which got this thread started!!! 
I'm pretty sure we still need the addition (somewhere below) to the 
psp_parser.l file.


Grisha


On Thu, 10 Nov 2005, Jim Gallacher wrote:


Gregory (Grisha) Trubetskoy wrote:


On Wed, 9 Nov 2005, Jim Gallacher wrote:

This just get's stranger and stranger. Regenerating psp_parser.c from 
the current psp_parser.l has caused my psp pages to go completely 
pair-shaped. Things that rendered correctly before now puke up 
hairballs.


For example the psp code (where my_link = 'some_url'):
   My Link
used to render as:
   My Link
but now renders as:
   My Link



You may find it useful to use the _psp module from the command line, since 
what you really want to see is not what it renders as, but the Python code 
it generates:



from mod_python import _psp
s = _psp.parse("/path/to/your/file")
print s


See below for test results.




Changing the double quote to a single quote fixes the problem.
   My Link



This doesn't make a lot of sense, because PSP does not concern itself with 
quotes - it scans for the "<%=" and once it has seen one then "%>", the 
quotes would remain untouched, so the problem is elsewhere.


I don't want to refactor *all* of my psp pages, so I guess we'll need to 
fix psp_parser. ;)



Just be careful, you may be trying to fix what is not broken in the first 
place. I use the 3.1.4 PSP very heavily and there is not a single glitch 
with it that I know of, and I can certainly use any kind of quote I want.


And this was my experience as well up to and including 3.2.4b, until I 
deleted psp_parser.c and regenerated it. Then everything went wrong with the 
site the I'm developing. I've been testing all the betas against this code 
since I figured I'd be more likely to spot strange problems. I did. :(


I'd start out with confirming your theory that psp_parser.c is stale 
somehow - that should be pretty easy - just generate a new one and diff it 
with what's in SVN.


$ svn co $MP_TRUNK /tmp/mod_python
$ cd /tmp/mod_python
$ ./configure
$ make
$ make install
$ echo "run parser test from command line"
$ mv src/psp_parser.c psp_parser.c.orig
$ make clean
$ make
$ make install
$ diff -u src psp_parser.c.orig psp_parser.c > psp_parser.diff
$ echo "re-run parser test from command line"

See attached diff. The 2 files are not the same.

Test results using mod_python._psp.parse('test.psp') from the command line 
interpreter:


test.psp

<%
x = ''
%>
test '<%= x %>'
test "<%= x %>"


Code generated from current psp_parser.c

req.write("""""",0);
x = ''
req.write("""
test '""",0); req.write(str( x ),0); req.write("""'
test \"""",0); req.write(str( x ),0); req.write("""\"
""",0)

Output from generated code (GOOD!)
--

test '

'
test "

"

Code generated with recreated psp_parser.c
--

req.write(r"""""",0);
x = ''
req.write(r"""
test '""",0); req.write(str( x ),0); req.write(r"""'
test """",0); req.write(str( x ),0); req.write(r""""
""",0)

Output from generated code (BAD!)
-

test '

'
test ,0); req.write(str( x

Re: [jira] Created: (MODPYTHON-87) psp_parser: replaces "\n" on \n

[Gregory (Grisha) Trubetskoy]

On Wed, 9 Nov 2005, Jim Gallacher wrote:

This just get's stranger and stranger. Regenerating psp_parser.c from the 
current psp_parser.l has caused my psp pages to go completely pair-shaped. 
Things that rendered correctly before now puke up hairballs.


For example the psp code (where my_link = 'some_url'):
   My Link
used to render as:
   My Link
but now renders as:
   My Link


You may find it useful to use the _psp module from the command line, since 
what you really want to see is not what it renders as, but the Python code 
it generates:



from mod_python import _psp
s = _psp.parse("/path/to/your/file")
print s



Changing the double quote to a single quote fixes the problem.
   My Link


This doesn't make a lot of sense, because PSP does not concern itself with 
quotes - it scans for the "<%=" and once it has seen one then "%>", the 
quotes would remain untouched, so the problem is elsewhere.


I don't want to refactor *all* of my psp pages, so I guess we'll need to fix 
psp_parser. ;)


Just be careful, you may be trying to fix what is not broken in the first 
place. I use the 3.1.4 PSP very heavily and there is not a single glitch 
with it that I know of, and I can certainly use any kind of quote I want.


I'd start out with confirming your theory that psp_parser.c is stale 
somehow - that should be pretty easy - just generate a new one and diff it 
with what's in SVN.


The most recent change in SVN seems to have been adding an 'r' before the 
triple quote for the  portion (r""" instead of just """), which 
should have solved some backslash problems.


Again, I haven't tested anything, but looking at the code, it seems to me 
that indeed there should be a problem exactly as Anton reported it and 
that my fix would be necessary, _and_ it may also apply to other special 
sequences such as tab \t. I may be missing something, but I just wnated to 
warn you that you may be missing something :-)


Grisha

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

[Gregory (Grisha) Trubetskoy]

So I guess this means we roll and vote on a 3.2.5b?

Grisah

On Sun, 6 Nov 2005, Nicolas Lehuen wrote:


OK, it looks like Alexis' fix solves the problem with ugh.pdf without
breaking the other unit tests. So I think we can safely integrate his patch.
Shall I do it ?

Regards,
Nicolas

Re: Linux FC 2 Test Failures (3.2.4b)

[Gregory (Grisha) Trubetskoy]

On Sun, 6 Nov 2005, Graham Dumpleton wrote:


Haven't had a chance to investigate yet and ensure they aren't caused by me
using versions of both Python and Apache not in standard locations. Most
tests work though. The tests that fail are:

==
FAIL: test_connectionhandler (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
 File "test.py", line 962, in test_connectionhandler
   self.fail(`rsp`)
 File "/home/grahamd/testing/lib/python2.3/unittest.py", line 270, in fail
   raise self.failureException, msg
AssertionError: '/home/grahamd/src/mod_python-3.2.4b/test/htdocs'

--
Ran 38 tests in 10.173s


If this is in an OpenVPS, then it has to do with 127.0.0.1 being 
transparently redirected to your IP, so what's in the log is not what is 
expected, or something to that extent - don't remember now, but it's all 
good, I wouldn't worry about this one.


Grisha

Re: PythonEnablePdb option.

[Gregory (Grisha) Trubetskoy]

On Thu, 3 Nov 2005, Graham Dumpleton wrote:


With the thought of mod_python perhaps ignoring the PythonEnabledPdb
option when not run in single process mode, is there a way using the
apache.mpm_query() function or some other function of determining that
Apache is running in single process mode?


I wonder if simply examining sys.argv would work?

Grisha

Re: Move changes from README to CHANGES file

[Gregory (Grisha) Trubetskoy]

Why not refer people to the docs, just like it was done for 3.2? Otherwise 
this is yet another file to maintain.


On Fri, 28 Oct 2005, Jim Gallacher wrote:


Hi Grisha,

Any objection if I split the "changes" from README to a new CHANGES file?

Jim

Re: Gentoo (Was: mod_python 3.2.3b available for testing)

[Gregory (Grisha) Trubetskoy]

I think the proper thing to do (i forgot about the cookie and x86-64 
issues) is to consider 3.2.3b as shut down by pre-release testing, so it's 
just going to be a version that will never be publicly released.


The next step is to apply the fixes you mentioned below and roll a 3.2.4b, 
then submit it to the list for test/vote for public release.


Grisha

On Thu, 27 Oct 2005, Jim Gallacher wrote:


Gregory (Grisha) Trubetskoy wrote:


If we don't get an resolution on this Gentoo issue - should we just go 
ahead and release the file anyway? Hopefully then someone will fix it 
before the final release?


Since we have not received any additional information on this I think we 
should proceed.


However there is also the issue of "Too many cookies using mod_python 3.2.2b" 
from a thread on the mod_python list. I don't know if we should generate 
another beta or just fix it in 3.2 final. The fix is very simple - remove 2 
lines which had been added for the get_session feature, but that feature 
didn't make it into 3.2.


There is also the issue of ./configure failing for x86-64 platforms. Again, 
it is a very simple fix - 3 lines in configure.in.


I'll create JIRA issues and commit the fixes for these real soon. (tonight - 
maybe).


To what extent can a final release differ from the last beta, Grisha? Is it 
OK to make some small changes from one to the other? When would changes be 
considered critical enough to require a new beta release round?


Regards,
Jim


Grisha


On Tue, 25 Oct 2005, Gregory (Grisha) Trubetskoy wrote:



Hmmm... Looking at /usr/lib/python2.4/httplib.py, sock.readline() gets 
an EOF upon reading the first byte. Do you see anything in the error 
logs associated with this, like a segfault?


To make it easier to isolate, try editing test.py to comment out all 
other tests and just leave this one. Look for a line that looks like:


   perRequestSuite.addTest(PerRequestTestCase("test_req_headers_out"))

and comment out every other test in this block but this one, then rerun 
it. At the end you should have a log file in the logs directory, 
hopefully it will contain a clue.


Thanks!

On Tue, 25 Oct 2005, Dominic Wong wrote:


-1 for Gentoo Linux 2.6.13-gentoo-r3
Apache 2.0.54
Python 2.4.1




* Testing req.headers_out
connect: (127.0.0.1, 32873)
send: 'GET / HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: 
test_req_headers_out:32873\r\n\r\n'

reply: ''
E




==
ERROR: test_req_headers_out (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 597, in test_req_headers_out
  response = conn.getresponse()
File "/usr/lib/python2.4/httplib.py", line 863, in getresponse
  response.begin()
File "/usr/lib/python2.4/httplib.py", line 333, in begin
  version, status, reason = self._read_status()
File "/usr/lib/python2.4/httplib.py", line 297, in _read_status
  raise BadStatusLine(line)
BadStatusLine

--

Re: Gentoo (Was: mod_python 3.2.3b available for testing)

[Gregory (Grisha) Trubetskoy]

If we don't get an resolution on this Gentoo issue - should we just go 
ahead and release the file anyway? Hopefully then someone will fix it 
before the final release?


Grisha


On Tue, 25 Oct 2005, Gregory (Grisha) Trubetskoy wrote:



Hmmm... Looking at /usr/lib/python2.4/httplib.py, sock.readline() gets an EOF 
upon reading the first byte. Do you see anything in the error logs associated 
with this, like a segfault?


To make it easier to isolate, try editing test.py to comment out all other 
tests and just leave this one. Look for a line that looks like:


   perRequestSuite.addTest(PerRequestTestCase("test_req_headers_out"))

and comment out every other test in this block but this one, then rerun it. 
At the end you should have a log file in the logs directory, hopefully it 
will contain a clue.


Thanks!

On Tue, 25 Oct 2005, Dominic Wong wrote:


-1 for Gentoo Linux 2.6.13-gentoo-r3
Apache 2.0.54
Python 2.4.1



* Testing req.headers_out
connect: (127.0.0.1, 32873)
send: 'GET / HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: 
test_req_headers_out:32873\r\n\r\n'

reply: ''
E



==
ERROR: test_req_headers_out (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 597, in test_req_headers_out
  response = conn.getresponse()
File "/usr/lib/python2.4/httplib.py", line 863, in getresponse
  response.begin()
File "/usr/lib/python2.4/httplib.py", line 333, in begin
  version, status, reason = self._read_status()
File "/usr/lib/python2.4/httplib.py", line 297, in _read_status
  raise BadStatusLine(line)
BadStatusLine

--

Re: Where do we stand on 3.2.2 final?

[Gregory (Grisha) Trubetskoy]

On Sat, 22 Oct 2005, Jim Gallacher wrote:


Alternative 1 - no version changes get committed to trunk:
Alternative 2 - two version changes get committed to trunk:


I think neither one is right. I should be:

svn co $URL/trunk trunk
cd trunk
 (Change the MPV_STRING to "3.2.xb")
svn ci -m "changed version in trunk"

# note the next line uses remote urls
svn copy $URL/trunk $URL/tags/release-3-2-xb

# note "export" not "co"
svn export $URL/tags/release-3-2-xb mod_python-3.x.x

The "export" command above should produce a clean set of files where you 
should not need to make any changes and be able to just tar it as is 
(well, except for the html documentation step).


Nicolas's SQLiteSession.py is still there, but it's the only experimental 
stuff.  Perhaps we should create a new experimental branch, or have 
individual branches for messing around.


Yep, I'm thinking we should try to keep the trunk closest to the 
official/current version and a branch for new experimental stuff. 
SQLiteSession should definitely not be included in the tarball.


Grisha

Re: Where do we stand on 3.2.2 final?

[Gregory (Grisha) Trubetskoy]

On Sat, 22 Oct 2005, Jim Gallacher wrote:

Just a note on updating src/include/mpversion.h. Should we be changing 
MPV_PATCH in svn trunk (and by extension MPV_STRING) to track the beta 
release patch level? In trunk we are still at MPV_PATCH 0, but in 
tags/release-3-2-2b we are at MPV_PATCH 2.


Hmm... It looks like you've set the version number in the tag. The tags 
should be completely static (i think there may be certain instances where 
you modify the tag but that's very rare). The version should have been set 
in the trunk, _then_ you create the tag.


Techincally the right way to solve this now is to merge the changes into 
the trunk, though I'll admit I've never done a merge with svn (yet). 
Another way is just to edit mpversion manually in the trunk ;)


While on the subject - didn't we have some experimental 3.3 stuff - is 
that in SVN, and if so, is it in the trunk, or do we have a branch for 
this?


Lastly, I agree, let's roll 3.2.3b ASAP.

Grisha

Re: Where do we stand on 3.2.2 final?

[Gregory (Grisha) Trubetskoy]

On Fri, 21 Oct 2005, Nicolas Lehuen wrote:


I can try to integrate Graham's proposal for a fix to MODPYTHON-83 and test
it on Win32 this week-end, but after that I'll be away for a week.


The 83 fix seems to be applicable to where WITH_THREAD is undefined (more 
and more rare these days), so the Win32 testing isn't really going to test 
anything, unless I'm missing something.


Grisha