Er, just as a notice, the second test for multipart/ was already
correct, but I've changed it to 'not ctypes.startswith(multipart/)'
for better code consistency.
Regards,
Nicolas
2005/9/8, Nicolas Lehuen [EMAIL PROTECTED]:
Hi Dominic,
That's perfectly acceptable. I've just used the
Hello,
I would like to point to some simple bug in session handling. The problem
occurs when you want to have persistens sessions, i.e. the ones which
will stay after the user close the browser window (this is useful for
example if you want to let him stay logged-on). For this reason it is
Jim Gallacher wrote ..
Gregory (Grisha) Trubetskoy wrote:
I've been away this weekend - just got back, but I'm too busy to try
to
read all the multiple-interpreter related comments. I guess my question
is - can someone provide a quick summary of how far we are from 3.2.1b
test
I don't use sessions enough to comment on whether this is an appropriate
change for mod_python or not, but I would suggest that you log an
enhancement request at:
http://issues.apache.org/jira/browse/MODPYTHON?report=select
This will ensure any request is not overlooked. It is also preferred
Gregory (Grisha) Trubetskoy wrote:
Anybody got FreeBSD? I'm getting this. This is an old and possibly
misconfigured system, so the problem could be on my end.
FreeBSD 4.9
apache 2.0.53 (from ports)
python 2.3.3
$ make
Compiling for DSO.
/usr/local/sbin/apxs
On Thu, 8 Sep 2005, Jim Gallacher wrote:
I don't have FreeBSD, or any experience with any BSD, but I won't let that
stop me from commenting. :)
I don't see apr-0 listed in your includes in the above output.
APR_THREAD_MUTEX_UNNESTED is defined in apr_thread_mutex.h, which on debian
is in
Gregory (Grisha) Trubetskoy wrote:
On Thu, 8 Sep 2005, Jim Gallacher wrote:
I don't have FreeBSD, or any experience with any BSD, but I won't let
that stop me from commenting. :)
I don't see apr-0 listed in your includes in the above output.
APR_THREAD_MUTEX_UNNESTED is defined in
2005/9/8, Jorey Bump [EMAIL PROTECTED]:
Jim Gallacher wrote:
Nicolas Lehuen wrote:
Well, why not keep our plan of releasing 3.2 ASAP and save this
problem for a later 3.2.x as a bug fix ?
Making subsequent bug-fix releases should be fast and easy. We cannot
afford to repeat the long
On 09/09/2005, at 10:02 AM, Jim Gallacher wrote:
As far as some future version breaking compatibility, I favour a
bigger jump in the major number: 3.2 - 4.0. This is server software
after all, and some people may prefer to maintain an older version for
a longer period, foregoing new features
