Hello, I posted this <http://Condition never met on process_response with
common middleware> on #django-users but I think here is the right place to
post it.
To give more context, this <https://github.com/wagtail/wagtail/issues/5331>
is the related issue on Wagtail which lead me here.
In general, if a user defines a "catch all non-recognized patterns"
URLpattern (let's call it catch-all-404) as Wagtail admin does, something
like:
# Default view (will show 404 page)
urlpatterns = [
... (some patterns here) ...
re_path(r'^', home.default),
]
the APPEND_SLASH setting has no effect.
For example, if */account/* is a valid path, when a user requests
*/account,* he will be routed to the catch-all-404 view, regardless of the
APPEND_SLASH setting. That is due to the check being done here
<https://github.com/django/django/blob/4ab3ef238edfa7c7b7c2c4420c7ae5b722bde121/django/middleware/common.py#L70>
which considers that the current path is a valid one since it matches the
catch-all-404 pattern.
This is not the desired behavior, for Wagtail admin at least.
Instead of calling the should_redirect_with_slash in the process_response
method
<https://github.com/django/django/blob/4ab3ef238edfa7c7b7c2c4420c7ae5b722bde121/django/middleware/common.py#L107>,
a trick I found to solve this issue is to call a
should_force_redirect_with_slash
method that directly checks if appending a slash to the current path turns
it into a valid one.
Its only difference with the should_redirect_with_slash method is skipping
the line highlighted above.
This seems very specific and I don't know if Django wants to handle this
itself (and if so, I don't know if it's going to be this way too) or rather
let the user adapt.
In both cases however, the current check being done in the process_response
method for the CommonMiddleware(here
<https://github.com/django/django/blob/4ab3ef238edfa7c7b7c2c4420c7ae5b722bde121/django/middleware/common.py#L105-L108>)
seems irrelevant to me unless I am missing *something*.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/6d39c5c0-bd79-48ec-8ae4-bad4ae023237n%40googlegroups.com.
