CommonMiddleware APPEND_SLASH doesn't handle request.urlconf

[archim]

If some middleware positioned before CommonMiddleware set request.urlconf to value other than ROOT_URLCONF, APPEND_SLASH will not work.
This is because it uses urlresolvers.resolve(path) without specifying urlconf.

Solution is something like this

--- /usr/lib/python2.5/site-packages/django/middleware/common.py	2009-01-07 17:31:28.000000000 +0200
+++ common_patched.py	2009-03-12 10:21:29.000000000 +0200
@@ -34,6 +34,10 @@
         settings.APPEND_SLASH and settings.PREPEND_WWW
         """
 
+	try:
+		urlconf = request.urlconf
+	except AttributeError:
+		urlconf = None
         # Check for denied User-Agents
         if 'HTTP_USER_AGENT' in request.META:
             for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
@@ -53,8 +57,8 @@
         # Append a slash if APPEND_SLASH is set and the URL doesn't have a
         # trailing slash and there is no pattern for the current path
         if settings.APPEND_SLASH and (not old_url[1].endswith('/')):
-            if (not _is_valid_path(request.path_info) and
-                    _is_valid_path("%s/" % request.path_info)):
+            if (not _is_valid_path(request.path_info, urlconf) and
+                    _is_valid_path("%s/" % request.path_info, urlconf)):
                 new_url[1] = new_url[1] + '/'
                 if settings.DEBUG and request.method == 'POST':
                     raise RuntimeError, (""
@@ -130,7 +134,7 @@
     # Different subdomains are treated as different domains.
     return referer is not None and re.match("^https?://%s/" % re.escape(domain), referer)
 
-def _is_valid_path(path):
+def _is_valid_path(path, urlconf=None):
     """
     Returns True if the given path resolves against the default URL resolver,
     False otherwise.
@@ -139,7 +143,7 @@
     easier, avoiding unnecessarily indented try...except blocks.
     """
     try:
-        urlresolvers.resolve(path)
+        urlresolvers.resolve(path, urlconf)
         return True
     except urlresolvers.Resolver404:
         return False

[Karen Tracey]

Looks like the same reported problem a #6228. It too has a patch, somewhat different. One thing preventing it from moving along seems to be lack of a test.