On lighttpd using scgi, the value of self.path_info and self.path in wsgi.py was exchanged.

[lizziesky]

An Django app was running under lighttpd using scgi protocol, but I found that it can only access the root url '/', access url, like, '/signup/', '/admin/', etc, it all response the content which is requested from the root url '/'.

Then, I tested like:
Django/core/handlers/wsgi.py, in class WSGIRequest, function init, the variable self.path_info and self.path have incorrect value, it lead to resolver.resolve(request.path_info) in base.py cann't find the correct call_back functions.

original code is:

    def __init__(self, environ):
        script_name = base.get_script_name(environ)
        path_info = force_unicode(environ.get('PATH_INFO', u'/'))
        if not path_info or path_info == script_name:
            # Sometimes PATH_INFO exists, but is empty (e.g. accessing
            # the SCRIPT_NAME URL without a trailing slash). We really need to
            # operate as if they'd requested '/'. Not amazingly nice to force
            # the path like this, but should be harmless.
            #
            # (The comparison of path_info to script_name is to work around an
            # apparent bug in flup 1.0.1. Se Django ticket #8490).
            path_info = u'/'
        self.environ = environ
        self.path_info = path_info
        self.path = '%s%s' % (script_name, path_info)
        #...

change to:

    def __init__(self, environ):
        script_name = base.get_script_name(environ)
        path_info = force_unicode(environ.get('PATH_INFO', u'/'))
        print script_name, path_info
        if not path_info or path_info == script_name:
            # Sometimes PATH_INFO exists, but is empty (e.g. accessing
            # the SCRIPT_NAME URL without a trailing slash). We really need to
            # operate as if they'd requested '/'. Not amazingly nice to force
            # the path like this, but should be harmless.
            #
            # (The comparison of path_info to script_name is to work around an
            # apparent bug in flup 1.0.1. Se Django ticket #8490).
            path_info = u'/'
        self.environ = environ
        if script_name == path_info:
            self.path_info = path_info
        else:
            self.path_info = '%s%s' % (script_name, path_info)
        self.path = path_info
        print 'after', self.path_info, self.path

After exchange self.path and self.path_info, it can find the right callback functions.

But it produced another problem that is in settings.py, FORCE_SCRIPT_NAME can't be set to , this is always used in fastcgi, if I set this value, it requested '/' again.

So I wonder if there are more suitable solutions? and why this happened?

Using original wsgi.py, why does it work well in fastcgi, but not in scgi??

[Graham Dumpleton]

You left debug statements in there.

Besides that, is there potentially something wrong with this for normal WSGI functioning.

What happens if have:

WSGIScriptAlias /a/b /some/path/site.wsgi

and the URL is:

/a/b/a/b

In this case, in WSGI environment you will have:

SCRIPT_NAME=/a/b
PATH_INFO=/a/b

This is not a duplicate of the information, but two distinct copies from different parts of the full URL.

If 'script_name' is set from 'SCRIPT_NAME' in WSGI environment and similarly, 'path_info' is set from 'PATH_INFO' in WSGI environment, then comparisons of 'path_info == script_name' will evaluate true where a sub URL of application corresponded to the mount point of the application.

If there is a workaround for FASTCGI/SCGI or flup, then they should only be done when it is known 100 percent that those environments are in use and that the bug is present. Trying to do magic fiddles all the time, on face value look likes it will cause problems for stuff which is valid for a correctly functioning WSGI adapter.

I'll try some experiments when I get a chance and look at code, but am I reading this right?

[lizziesky]

very sorry, I made a mistake in configuring url info in lighttpd.conf.
so there is no problem with self.path_info and self.path . It's just my stupid misunderstanding.

thanks you all the same.