Opened 13 years ago
Last modified 9 years ago
#17133 closed Cleanup/optimization
get_script_name goofs when there is Apache URL rewriting — at Initial Version
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When running under Apache+mod_wsgi (I'm not sure the mod_wsgi is relevant here), using a WSGIScriptAlias of /foo, a request for URL /foo/barbaz (note double slash) gets transformed by Apache to /foo/bar/baz and then by Django to /foobar/baz (note where double slashes are now). Furthermore, a callback function for urlpattern "bar/.*" will be called on this latter path even though it doesn't match the pattern. That is, request.path will be "/foobar/baz", which can be confusing for a callback function that is expecting request.path to match the WSGIScriptAlias plus the urlpattern.
I don't totally understand what Django is doing here, but I believe the problem is in django.core.handlers.base.get_script_name. In that function, to get the script name in this situation Django starts with the environment variable SCRIPT_URL, and strips off a number of characters at the end equal to the length of environment variable PATH_INFO. Because in this case Apache collapses the double slash in /foo/barbaz to /foo/bar/baz, get_script_name strips off one less character than necessary, so that instead of the script name being /foo it is /foo/. This may account for the double slash appearing /foo, as in /foobar/baz.