
| Key: |
MODPYTHON-31
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Won't Fix
|
| Priority: |
Blocker
|
| Assignee: |
Unassigned
|
| Reporter: |
Jarkko
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Using Fedora Core 3.
--
# rpm -q httpd
httpd-2.0.52-3.1
--
--
# rpm -q mod_python
mod_python-3.1.3-5.2
--
Using Fedora Core 3.
--
# rpm -q httpd
httpd-2.0.52-3.1
--
--
# rpm -q mod_python
mod_python-3.1.3-5.2
--
|
|
| Resolution Date: |
09/Apr/05 05:58 PM
|
|
/etc/httpd/conf.d/python.conf
--
# Add .psp to types
AddType application/x-httpd-psp .psp
# Handle .psp documents with mod_python
AddHandler mod_python .psp
PythonHandler mod_python.psp
# Add index.psp to index documents
DirectoryIndex index.psp
# Enable debug under /psp directory
<Directory /var/www/html/psp>
AddHandler mod_python .psp_
PythonDebug On
</Directory>
--
/var/www/html/psp/index.psp
--
<html>
sid: <%=session.id()%>
</html>
--
lynx localhost/psp
--
Mod_python error: "PythonHandler mod_python.psp"
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 299, in
HandlerDispatch
result = object(req)
File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 297, in
handler
p.run()
File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 191, in run
session = Session.Session(req)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 389, in
Session
timeout=timeout, lock=lock)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 294, in
__init__
timeout=timeout, lock=lock)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 132, in
__init__
Cookie.add_cookie(self._req, self.make_cookie())
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 160, in
make_cookie
c.path = dirpath[len(docroot):]
TypeError: unsubscriptable object
--
First the page worked like a charm. But then I figured I'd like to see how
mod_python handles a situation where the page has an infinite loop in it.
I coded a page with a code like "while True:" etc. in it and ran it. (The code
had a call to session too, so session was initialized.) I noticed that the
script was newer killed (this is bad, PHP handles this with its time limit). I
had to restart httpd then (which killed the script).
Now after that loop test the session variable does not work anymore. I get
that "unsubscriptable object" error message.
I figured that maybe the session data is corrupted and deleted the dbm file
from /tmp. That did not help. I've also restarted httpd multiple times.
The weirdest thing about this is that the httpd is preforked, so the session
should exists only in memory. If the session exists only in memory, restarting
httpd should be enough.
Where can that corrupted session data be stored now? Does httpd save its state
into some files? Even rebooting the whole machine did not help.
I consider this bug a very serious thing because this is a blocker. Sessions
don't work anymore.
Also, some kind of handling for infinite loops should be implemented. Yes I
know, that should be described in another bug report, but let's fix this
session thing first.
I have high hopes for mod_python as it integrates an excellent language to an
excellent web server and because it enables a powerfull and easy alternative to
PHP.
|
|
Description
|
/etc/httpd/conf.d/python.conf
--
# Add .psp to types
AddType application/x-httpd-psp .psp
# Handle .psp documents with mod_python
AddHandler mod_python .psp
PythonHandler mod_python.psp
# Add index.psp to index documents
DirectoryIndex index.psp
# Enable debug under /psp directory
<Directory /var/www/html/psp>
AddHandler mod_python .psp_
PythonDebug On
</Directory>
--
/var/www/html/psp/index.psp
--
<html>
sid: <%=session.id()%>
</html>
--
lynx localhost/psp
--
Mod_python error: "PythonHandler mod_python.psp"
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 299, in
HandlerDispatch
result = object(req)
File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 297, in
handler
p.run()
File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 191, in run
session = Session.Session(req)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 389, in
Session
timeout=timeout, lock=lock)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 294, in
__init__
timeout=timeout, lock=lock)
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 132, in
__init__
Cookie.add_cookie(self._req, self.make_cookie())
File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 160, in
make_cookie
c.path = dirpath[len(docroot):]
TypeError: unsubscriptable object
--
First the page worked like a charm. But then I figured I'd like to see how
mod_python handles a situation where the page has an infinite loop in it.
I coded a page with a code like "while True:" etc. in it and ran it. (The code
had a call to session too, so session was initialized.) I noticed that the
script was newer killed (this is bad, PHP handles this with its time limit). I
had to restart httpd then (which killed the script).
Now after that loop test the session variable does not work anymore. I get
that "unsubscriptable object" error message.
I figured that maybe the session data is corrupted and deleted the dbm file
from /tmp. That did not help. I've also restarted httpd multiple times.
The weirdest thing about this is that the httpd is preforked, so the session
should exists only in memory. If the session exists only in memory, restarting
httpd should be enough.
Where can that corrupted session data be stored now? Does httpd save its state
into some files? Even rebooting the whole machine did not help.
I consider this bug a very serious thing because this is a blocker. Sessions
don't work anymore.
Also, some kind of handling for infinite loops should be implemented. Yes I
know, that should be described in another bug report, but let's fix this
session thing first.
I have high hopes for mod_python as it integrates an excellent language to an
excellent web server and because it enables a powerfull and easy alternative to
PHP. |
Show » |
| There are no subversion log entries for this issue yet.
|
|