Opened 16 years ago
Closed 16 years ago
#11207 closed (wontfix)
On lighttpd using scgi, the value of self.path_info and self.path in wsgi.py was exchanged.
Reported by: | lizziesky | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.0 |
Severity: | Keywords: | lighttpd, scgi, path_info, script_name | |
Cc: | Graham.Dumpleton@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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??
Change History (3)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Cc: | added |
---|
comment:3 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
You left debug statements in there.
Besides that, is there potentially something wrong with this for normal WSGI functioning.
What happens if have:
and the URL is:
In this case, in WSGI environment you will have:
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?