On 08/06/2005, at 8:33 AM, Barry Pearce wrote:
Indeed Im for fixing it...its on my list of things to do...right after
'do everything the company want RSN'
I do believe it should be mod_python that is fixed. I have a VERY big
need for reload of modules *without* taking down my server -
I can see two problems here. The first is that if the target of the
internal redirect is a part of the URL namespace which is under the
control of a different handler, or where ApplicationPath option was set
explicitly to be different, the PYSID would potentially override a valid
pysid
Sorry, getting a bit overwhelmed with all these rapid changes in state
of things as bit busy today. Will probably will only know what is going
on when I look at latest code in repository. Then I'll probably pipe in
with some more pertinent comments about 3.2.
One report I would like to get some
URL: http://issues.apache.org/jira/browse/MODPYTHON-37
Project: mod_python
Type: New Feature
Components: core
Versions: 3.1.4
Reporter: Graham Dumpleton
Priority: Minor
Fix For: 3.2.0
Attachments: register_cleanup.diff.txt
The only way to register cleanup
A few comments:
1. If you have an older version of flex than that expected, it gives
message:
checking flex version... configure: WARNING: Flex version 2.5.31 or
greater is required. The one you have seems to be 2.5.4. Use
--with-flex to specify another.
There is nothing in the README
On 19/08/2005, at 2:59 AM, Jim Gallacher wrote:
Ron Reisor wrote:
Hello,
I ran into a problem with the loader on MacOSX.
MaxOSX 1.4.2
python 2.4.1
apache 2.0.54
The loader seems to not like the -undefined suppress arguments in
the final load.
I modified dist/setup.py by removing the two
On 19/08/2005, at 7:57 AM, Graham Dumpleton wrote:On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello,I ran into a problem with the loader on MacOSX.MaxOSX 1.4.2python 2.4.1apache 2.0.54The loader seems to not like the "-undefined suppress" arguments in the fi
/apache.py, line
454, in import_module
f, p, d = imp.find_module(parts[i], path)
ImportError: No module named index
We should create a new JIRA issue. If it turns out that the fix is not
easy, is this a big enough problem to hold up the 3.2 release?
Regards,
Jim
Graham Dumpleton wrote:
In 3.2
On 01/09/2005, at 6:19 AM, Jim Gallacher wrote:Hey Gang,I think we are ready for the 3.2.1b release. If there are no objections in the next 24 hours I'll create the package and make the announcement on python-dev.Sounds good.I'll always be hoping to sneak in just one more change (eg.
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
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
Jim Gallacher wrote ..
Indrek Järve wrote:
Jim Gallacher wrote:
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
+1 on
Jim, is this just confirming that test shows a problem with unpatched
3.2
or when Boyan's GIL state fixes are also applied? I haven't tried the
suggested patches yet, as wanted an answer as to why GIL state API had
to be
explicitly used, which he has now done so.
Graham
On 03/11/2005, at
The documentation for the Python debugger support in mod_python states:
Because pdb is an interactive tool, start httpd from the command line
with the -DONE_PROCESS option when using this directive. As soon as
your
handler code is entered, you will see a Pdb prompt allowing you to
step
Graham Dumpleton wrote ..
Grisha wrote ..
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
On 06/11/2005, at 2:42 AM, Jim Gallacher wrote:
The changes work fine on:
Mac OS X (10.3.9) / Apache 2.0.51 (worker) / Python 2.3 (Apple OS
Installed)
Linux Fedora Code 2 / Apache 2.0.55 (prefork) / Python 2.3.5
Test example was gilstate.tar.gz attached to MODPYTHON-77.
Also passed on
On 06/11/2005, at 11:55 AM, Gregory (Grisha) Trubetskoy wrote:
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
Hmmm, go away for two days and a mail storm erupts. :-(
I may never be able to catch up and digest this mail thread, but I'll
try and add a few comments of my own.
On 01/12/2005, at 8:41 AM, Nicolas Lehuen wrote:
c) We don't have a req.base_uri (to follow Jim's naming suggestion)
or
I'm a bit confused by:
- The only trick is that you'll have to stop your Apache server
before launching
the test, as the start/stop command can only apply to one single
Apache instance.
Does this apply to UNIX as well as Win32?
I ask as I have never bothered to explicitly shut down any
On 18/12/2005, at 3:09 AM, Jim Gallacher wrote:
We had talked about doing a 3.2 final release just after ApacheCon.
A couple of things have cropped up which we have (or should) fix, but
these will not be substantial changes from 3.2.5b. As such I think we
should do another beta followed
The other bug:
http://issues.apache.org/jira/browse/MODPYTHON-99
also recently found and related, may also be a contributor to the
problems
you are seeing. As Nicolas pointed out, doing introspection on the
request
object seems to be the flavour of the month.
BTW, has anyone though to
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
files which include stuff like
common page layouts etc.
Anyway, just toying with ideas.
Graham
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
On 21/12/2005, at 3:32 PM, Graham Dumpleton wrote:
Grisha wrote ..
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
Grisha, do you remember why the following warning is present
In a hurry, so a quick note. In 3.2, mod_python.publisher was changed
to read:
if req.method!='HEAD':
# TODO : the problem is that a handler can still use
req.write
# and break the assumption that nothing should be written
with the
# HEAD method.
Grisha wrote ..
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
You are a few weeks too late. :-)
See:
http://issues.apache.org/jira/browse/MODPYTHON-98
There are whole bunch of little issues with adding handlers using
req.add_handler(). For this one you seem to have tread much the
same path as I did.
Graham
Joseph Barillari wrote ..
Hi,
So far, I
Grisha wrote ..
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
On 05/01/2006, at 3:15 PM, Gregory (Grisha) Trubetskoy wrote:
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
Jim Gallacher wrote ..
Howdy gang.
I got distracted by some other stuff for a while there and didn't push
the 3.2.6 forward. So much for the master plan of releasing 3.2 before
the end of 2005. :(
There is quite a bit of mail to catch up on, but a quick perusal
indicates that the only
Graham Dumpleton wrote ..
The only other candidates that one might seriously consider are:
http://issues.apache.org/jira/browse/MODPYTHON-105
Simple change and Grisha agreed that should truncate output for HEAD.
That should have said should NOT truncate.
Graham
] [notice] mod_python: (Re)importing module
'tests'
[Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1]
accesshandler_add_handler_to_empty_hl
Regards,
Nicolas
2006/1/12, Jim Gallacher [EMAIL PROTECTED]:
Graham Dumpleton wrote:
On 12/01/2006, at 11:10 AM, Jim Gallacher wrote
Jim Gallacher wrote ..
It's a strange one. When I move site-packages/PIL to
site-packages/PIL.bak (leaving PIL.pth as is) and run the tests I get
the same output as Graham and Nicolas. I'm just going to ignore this for
the time being and go with a refactored unit test.
I am making a guess
A few weeks back I created a JIRA entry relating to integrating server
side includes with Python. The entry is:
http://issues.apache.org/jira/browse/MODPYTHON-104
I finally got around to having a go at implementing it and have some
initial code now working. The point of this email is to get
On 23/01/2006, at 4:59 PM, Deron Meranda wrote:
I like the SSI feature. It would fill a nice gap between using
plain HTML files and having to go to a more featured template
or engine. Some things are simple enough that the SSI concept
should be enough, and having Python would be nice.
I do
On 24/01/2006, at 3:07 AM, Deron Meranda wrote:
On 1/23/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Using print like that can't be done in an eval, would need to
use exec.
Sorry, I probably didn't mean to use the print in my example.
Of course though you can always wrap sys.stdout if you
On 26/01/2006, at 11:48 PM, Mike Looijmans wrote:
Two comments:
1. (bug): The acquire() call should be *outside* the try ... finally
block. You do not want to release a lock that you did not aquire.
Whoops. Quite agree. One hopes that acquiring a simple mutex lock never
fails though. If it
Jim Gallacher wrote ..
Graham Dumpleton wrote:
Thus, trade off of speed versus correctness is probably reasonable as
it
will
not cause a failure. In general I tend towards robustness and unexpected
surprises and that is why the code was written as it was.
Personally I tend towards
Jim Gallacher wrote ..
It seems like any 3.2.6 testing that is going to be done, has been done.
How long do we wait before making a decision for an official release.
If we don't get cracking on 3.3 soon Graham's gonna fill another couple
of pages on JIRA and we'll never catch up. :)
You
Barry Pederson wrote ..
As I mentioned in another message, I did some experimenting with
disabling other unittests and found if you disable just
test_fileupload, all the remaining tests including
test_connectionhandler pass.
If you disable everything except test_fileupload and
Grisha wrote ..
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) {
Changed subject heading. See more of what I have uncovered below.
Not sure where to go next.
Graham Dumpleton wrote ..
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
On 30/01/2006, at 9:11 PM, Matt Carpenter wrote:
Hi,
Not sure if this is best posted here, or to mod_dav mailing list.
But here goes.
Has anyone looked at using mod_python to backend mod_dav, with a
similar usage to FUSE's python binding. Basically mod_dav_python.
Others may know what
Graham Dumpleton wrote ..
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
Graham Dumpleton wrote ..
Extending the above code as:
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
An initial few comments from a first pass through.
def _write(self, request, response, content_type='text/xml'):
request.send_http_header()
request.content_type = content_type
request.write(response)
This is technically wrong, although it doesn't matter on mod_python
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:
This is a resend to python-dev list of an email I sent yesterday. For
some reason oaccsional email I am sending to list from home is
dissappearing, although people cc'd it are getting it. Apologies if
this is a duplicate.
On 30/01/2006, at 9:49 PM, Matt Carpenter wrote:
Graham Dumpleton wrote
On 02/02/2006, at 6:52 AM, Deron Meranda wrote:
Actually it seems that this is yet another case of trying to get
mod_python to hook into more places in the Apache framework;
specifically to hook into other modules.
We've already been discussing specific-module hooks for
mod_ssl -
Again this is a resend. I post one message via my secure SMTP and it
vanishes. Post one via normal SMTP and it goes to list straight away.
This sort of confirms what I suspected which is that my ISPs secure
SMTP is busted somehow in that randomly drops email. :-(
Sorry for the duplicate if first
I was looking at the new module importer used by mod_python.publisher in
3.2.6 to see whether it reloaded a module if file was replaced with an
older file and have come across some code that worries me a bit. Can
someone else (not just Nicolas) check this code and how it is used in
the context of
the file to stat it?
Graham
Graham Dumpleton wrote ..
I was looking at the new module importer used by mod_python.publisher in
3.2.6 to see whether it reloaded a module if file was replaced with an
older file and have come across some code that worries me a bit. Can
someone else (not just Nicolas
Graham Dumpleton wrote ..
Okay, false alarm (I think). Have got myself worked up over nothing.
I missed something very important:
timestamp = fstat(opened.fileno())[-2]
That is the '[-2]' in the above.
I feel like a goose now.
Now for some explaination of why my brain turned off
Nicolas Lehuen wrote ..
Well, I thought that if the file was modified, we needed to open it
anyway, but you're right, that's optimising for a minority case. We
might as well use stat and open the file only if it has changed.
I've wrote an alternative publisher a few months ago that
Nicolas Lehuen wrote ..
2006/2/2, Graham Dumpleton [EMAIL PROTECTED]:
Note that up until now I hadn't even looked over how this new module
importer was implemented. I knew it wasn't going to solve various of
the
existing module importer problems and I knew it was actually going
On 02/02/2006, at 5:54 PM, Nicolas Lehuen wrote:
Having read your work on Vampire (and its
module importing mechanism) I'm pretty sure it won't be long.
The new importer is actually a complete rewrite and some things
are done quite differently to what was done in Vampire. I have in
effect
Daniel J. Popowich wrote ..
PS
If it's not obvious I'm gearing up to get way more involved...I've
been waiting (patiently) for 3.2 to be released and jump in with new
3.3 development...I guess I'm chomping at the bit...
We probably want to defer until after 3.2.7 (final) is released to have
Very interesting. I'll only comment on one issue right now.
Daniel J. Popowich wrote ..
o And...no suprise...I'd like to try to sell mpservlets for
inclusion in the main distro. No tears if it's not, but I think
it fills a void and I'd like to make a case for its inclusion.
I
Jim, Nicolas
Would it make sense to change test_Session_Session_conf() function in
unit tests to something like:
def test_Session_Session_conf(self):
import tempfile
tempdir = tempfile.gettempdir()
database = os.path.join(tempdir,mp_sess_test.dbm)
c =
Grisha
I have a really obscure question for you.
Was there a specific reason that mod_python did not allow a handler
to be hooked using ap_hook_map_to_storage()?
I know that the reasons for wanting to do this would be very limited,
such as if you wanted to implement some sort of equivalent to
Nicolas Lehuen wrote ..
OK so my core group vote is +1 for this release.
It has been tested on a wide array of OSes, both threaded and forked
MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test
on MacOSX and Solaris would have been great but maybe the recommended
MPM on
Jim Gallacher wrote ..
Graham Dumpleton wrote:
The next section of code has:
b = APR_BRIGADE_FIRST(self-bb_in);
if (b == APR_BRIGADE_SENTINEL(self-bb_in))
return PyString_FromString();
Now I am assuming here that the check with APR_BRIGADE_SENTINEL
Automation
Graham Dumpleton wrote:
Mike, I have a feeling that Apache has ways of generating those date/time
strings for last modified for you. Thus, the routine shouldn't be required.
The real problem is that mod_python doesn't expose the methods which
may actually be useful to you
I know the subject line doesn't mean much, but I want to outline an
idea I have for an addition to mod_python which would help solve
a few problems. The mail is likely to be long, but if people can
understand
what I am going on about, I would appreciate some feedback.
Some background
On 12/02/2006, at 2:40 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
snip
Thus we come to my actual idea that I want some feedback on.
The idea is to provide a new directive in mod_python that allows
you to mark
an arbitrary point in the directory hierarchy as a context point
Jim Gallacher wrote ..
Jorey Bump wrote:
Jim Gallacher wrote:
This is how I would set priorities:
Try and assign most of the issues to someone. This is a bit of PR
spin, but I think it looks bad when there are a large number of open
issues with no assignee. To the public it
Jim Gallacher wrote ..
If the settings are going to be a generic key/value like in
PythonOption, but only for purposes of the mod_python system itself,
maybe it should be called PythonSystemOption. Prefer PythonSystemOption
as Module is too confusing to me given you have both Apache
Jim Gallacher wrote ..
I have a better option (pun intended). :-)
We do not need a new directive. Instead use existing PythonOption
directive.
That could work.
In the handler code for the directive, it can look at the
value of the cmd_parms-path and determine if it is being used
Graham Dumpleton wrote ..
Graham Dumpleton wrote ..
How does req.server.get_options() differ from req.server.get_config(),
which already exists?
I still see what is in get_config() as special, ie., the values for
actual directives. Just don't think it is good to mix them.
Looking
Daniel J. Popowich wrote ..
Graham Dumpleton (JIRA) writes:
If mod_python is to still support Python 2.2, which it looks like we
are still because of Nokia work, then can't use the Python bool type
yet as that was only added to Python 2.3.
But can't a decision be made? I think
On 19/02/2006, at 9:35 AM, Jim Gallacher wrote:
I just noticed that write is declared twice in request_methods
[] . What's up with that??
src/requestobject.c
static PyMethodDef request_methods[] = {
...
... line 1075
{write, (PyCFunction) req_write, METH_VARARGS},
I already fixed the test and checked it in. :-)
On 20/02/2006, at 5:15 AM, Jim Gallacher wrote:
Yes, this test seems to be broken. I'll create a JIRA issue for it.
We need unit tests for the unit tests. :)
Jim
For my WTF moment, have a look at test_req_get_basic_auth_pw in the
test suite.
Jim Gallacher wrote ..
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
If that is what closed implies. Is there somewhere which states what we
should interprete the different status as meaning? I don't recollect seeing
anything
Jim Gallacher wrote ..
Other JIRA thoughts:
Should we have a unit test component for bugs in the actual unit test
code?
Since we plan on having 3.2.x bugfix releases, should create new JIRA
versions starting with 3.2.7?
No harm in doing so. Probably would only be used if reported
Jim Gallacher wrote ..
All very interesting, except that JIRA does record the svn commit info,
and with great detail. It just doesn't treat the commit as a comment.
For example:
http://issues.apache.org/jira/browse/MODPYTHON-124?page=all
Personally I think the Subversion commit
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:
+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
On 21/02/2006, at 7:08 AM, Jim Gallacher wrote:
The Apache 2.2 support will likely go into the 3.2.9 bugfix release.
We just wanted to get the security problem out of the way first.
Jim, if we are again going to aim for a bug rollup release for 3.2.9
do I
need to stop or hold off on doing
published function.
Graham
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
Jim Gallacher wrote ..
Justin Erenkrantz wrote:
On 2/19/06, Jim Gallacher [EMAIL PROTECTED] wrote:
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this
is
an error and that *everything* should be
On 26/02/2006, at 5:58 AM, Jim Gallacher wrote:
Since we are discussing Python*Filter, can someone explain why it
is only allowed in the server config context, whereas
SetInputFilter and related directives are allowed in any context?
Is this a mod_python feature or a bug, or is it just
One of the problems when I am looking at making changes to mod_python
is knowing that there is some consensus that changes are a good
thing, or
at least that there is no objection.
So far if a change was trivial, I would commit it without
consultation. I have
also committed some changes
On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
More in the way of a general observation rather than on these
specific issues, but I wouldn't necessarily mark things as resolved
just on the basis of the fix being committed. For the big changes
at least, I think we should see some
/* Bad file descriptor */
Maybe when I am really bored I'll pursue further as to why.
Graham
On 06/03/2006, at 10:27 PM, Graham Dumpleton wrote:
Don't even need to rewrite test to use threads to fire off
requests. If
I hardwire test to use ab from Apache 1.3 or Apache 2.0
Nicolas
A while back you made the following change:
r378072 | nlehuen | 2006-02-16 06:41:25 +1100 (Thu, 16 Feb 2006) | 5
lines
- Fixed the unit tests for apache.register_cleanup
server.register_cleanup. Ther
e is not way it could have passed before, yet it did ???
- Corrected the
Jim Gallacher (JIRA) wrote ..
I think part of the problem with process_auth() is the uncertainty of meaning
associated with auth and __auth__. Does it mean authenticate or authorize?
If it's authorize, then there is no reason to call __auth__ with the password.
Likewise, you shouldn't need the
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
On 12/03/2006, at 8:25 PM, André Malo wrote:
* Graham Dumpleton wrote:
Not seeing any negatives, I am going to go ahead and commit the SSI
stuff. Comments that this is just another way to skin a cat are true,
even if a small cat. I guess the reason for doing it is to fill out
those basic
On 12/03/2006, at 9:04 PM, Graham Dumpleton wrote:
On 12/03/2006, at 8:25 PM, André Malo wrote:
* Graham Dumpleton wrote:
Not seeing any negatives, I am going to go ahead and commit the SSI
stuff. Comments that this is just another way to skin a cat are true,
even if a small cat. I guess
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
Grisha wrote ..
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
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)
Jim Gallacher wrote ..
Which is all good, but you are assuming that people are only using
sessions for authentication purposes. Consider a shopping cart
implemented as session: the user may not be authenticated until *after*
they have filled their cart and are ready to checkout. Perhaps the
On 15/03/2006, at 8:45 AM, Gregory (Grisha) Trubetskoy wrote:
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):
$
I know this is the wrong list to be asking this, but thought I
would ask before I go and get my self subscribed to some Apache
server list just to ask the question as I know some more involved
in Apache core lurk here. :-)
I have been looking at a way of solving:
as a non versioned file.
You will need to remove the file before doing svn update.
Graham
On 17/03/2006, at 3:17 PM, Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-118?page=all ]
Graham Dumpleton resolved MODPYTHON-118
Now can you explain why one would want to do this?
Unless you provide some justification of why it is necessary it is
less likely
to be accepted as although the reasons may be obvious to you, it may not
be to us. There also may be better ways of achieving the same end.
Also, describe why
Firat KUCUK wrote ..
Hi,
i have a little problem about Directory Index.
this is our .htaccess file:
Allow from All
AddHandler mod_python .py
PythonHandlerwepy.handler
PythonDebug On
DirectoryIndex index.htm index.html index.php index.py index.pl
wepy is
to
solve. On first appearances, your solution would seem to be going
about it the wrong way.
A question for others. Would it be reasonable that a cookie is not
written out if SID was supplied explicitly?
Graham
Graham Dumpleton wrote ..
Now can you explain why one would want to do this?
Unless
1 - 100 of 697 matches
Mail list logo
