Debug 404 page shouldn't include the request path prefix in the description of URLconf matching

[Tzu-ping Chung]

When I served a site under a prefix, and the site gets a 404, the default (debug) page shows something like

Using the URLconf defined in ..., Django tried these URL patterns, in this order:

1. ^foo/$
2. ^bar/whatever$

The current URL, prefix/foo/bar/, didn't match any of these.

The “The current URL” part shows the complete path, i.e. with the prefix I served Django under. This is very confusing because Django does not actually match it with the patterns. Looking into the code it seems the 404 handler (django.views.defaults.page_not_found) should use request.path_info instead of request.path in its context.

[Tzu-ping Chung]

A little more info:

This is where Django finds a match for this URL.
​https://github.com/django/django/blob/44a6b40/django/core/handlers/base.py#L172

And this is where it shows the URL on the 404 page.
​https://github.com/django/django/blob/44a6b40/django/views/defaults.py#L40

[Tim Graham]

The "Using the URLconf..." text is from the TECHNICAL_404_TEMPLATE -- this goes through the technical_404_response() view rather than page_not_found(). Modifying page_not_found() seems incorrect since in a production setting, the full path is likely desired. I'm not certain if the ​request_path in the technical_404_reponse() can be modified to fix the issue you described. Do you want to investigate further?

[Marten Kenbeek]

I only see the path_info in the debug view technical_404_response(), not the full path. Looking through the actual debug view confirms this behaviour as well -- the URL resolver is only passed the path_info, so if a Resolver404 exception occurs, exception.args[0]['path'] can only contain the path_info, not the path. The else clause uses request.path_info.