modpython handler behaves differently when url matches existing file

[Arthur Hebert]

I am migrating my site from PHP to Django, so my public_html directory is full of my old files, such as index.php. Such files are no longer loaded by apache, because they are overridden by /etc/apache2/modules.d/16_mod_python.conf:

...
<Directory /space/arthur/public_html/>
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE artybear.settings
    PythonPath "['/home/arthur/projects'] + sys.path"
    PythonDebug On
</Directory>
...

If I request a url that points to the name of a file that exists under the public_html/ directory (not including the file's extension), then I get the following error:

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
    result = object(req)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 177, in handler
    return ModPythonHandler()(req)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 137, in __call__
    os.environ.update(req.subprocess_env)

  File "/usr/lib/python2.4/os.py", line 478, in update
    self[k] = dict[k]

  File "/usr/lib/python2.4/os.py", line 463, in __setitem__
    putenv(key, item)

TypeError: putenv() argument 2 must be string, not list

For example, artybear.com/foobar will return the Django debug page, but artybear.com/index will give the error above. If I remove the file index.php from the public_html/ directory, then artybear.com/index will return the Django debug page.

Oddly, artybear.com/index.php will return the Django debug page. The problem only seems to occur when the url points to the basename of a file that Apache would otherwise handle with another program. Some further tests:

$ cd /space/arthur/public_html/
$
$ touch foobar.php            # artybear.com/foobar returns error page
$ mv foobar.php foobar        # artybear.com/foobar returns Django debug page
$ mv foobar foobar.txt        # artybear.com/foobar returns error page
$ mv foobar.txt foobar.foo    # artybear.com/foobar returns Django debug page

This is problematic if there's a file called admin.php, because it returns the error page instead of the mapped url (Django's admin page).

I have Django source revision 4193, according to svn update.

[James Bennett]

This sounds like an Apache configuration issue; the input coming from apache itself is bad, and is causing Django to error out.

Make sure that there are no directives in your httpd.conf telling Apache to use other handlers (like mod_php) for file types which exist in that directory; IIRC, Apache calls all listed handlers, in order, while processing a request, not just the first or last one found.

[Arthur Hebert]

You are right. I am unable to fix this on the mentioned system, but I just got to try out a newly installed server, and it does not produce the error.

[Chris Beaven]

If it's working on a newly installed server, then let's put it down to a misconfiguration. If anyone else has this problem, please re-open.

[whoisthenirk]

New to Django and having a very similar problem. The exact same error message comes up only when i access a .py file without the ".py" in the URL. Likewise when any other URL is entered, I get the Django error page instead.

My httpd.conf:

<location "/miniFBpy">

    SetHandler python-program
    
    PythonHandler django.core.handlers.modpython
    
    PythonPath "['/home/nick/django_projects'] + sys.path"
    
    SetEnv DJANGO_SETTINGS_MODULE miniFBpy.settings
    
    PythonOption django.root /miniFBpy
    

    PythonDebug On
    
</location>

My apache2 default file:

	<Directory /var/www/>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
		AddHandler mod_python .py
		PythonHandler mod_python.publisher
		PythonDebug On
	</Directory>

However, if I forsake the "PythonHandler django.core.handlers.modpython" and simply maintain the PythonHandler as mod_python.publisher, the .py page becomes accessible -- but naturally the Django error pages disappear. However, forsaking the "PythonHandler mod_python.publisher" and maintaining the django.core.handlers.modpython as the PythonHandler makes no difference, and the same error results.

[Karen Tracey]

#9327 describes a different situation that leads to the same traceback. Closing this in favor of that because that one has a clear understanding of what Apache/mod_python behavior leads to the problem.