And follow more closely the class of characters defined in the
RFC 3986.
Thanks Erik van Zijst for the report and the initial patch, and
Tim Graham for the review.
- Fixed bug in get_callable() that caused resolve() to put a string
in ResolverMatch.func.
- Made ResolverMatch.url_name match the actual url name (or None).
- Updated tests that used the string value in ResolverMatch.func, and
added regression tests for this bug.
- Corrected test urls whose dummy view paths caused failures (behavior
that was previously masked by this bug).
Fixed URL resolving in the case where an outer regex includes an inner
regex and both regexes use positional parameters instead of named
groups, causing the outer regex's parameters to override the inner
regex's.
Modified the regex url resolver so that it will concatenates and then
normalizes, instead of normalizing and then concatenating.
The new error message now hints that the most likely issue
is a circular import.
Thanks to trac user elena for the report and to
bpeschier for the original patch.
Commit 79558c78 cleaned up the (undocumented) interface of Resolver404
exception, which breaks compatibility with code messing with .args[0]
directly. Revert the cleanup part and simply leave the fix itself.
When django.core.urlresolvers.resolve was called from a view, failed
and the exception was propagated and rendered by technical_404_response,
the URL mentioned on the page was the current URL instead of the URL
passed to resolve().
Fixed by using the path attribute from the Resolver404 exception instead
of request.path_info. Also cleaned up the exceptions to use standard
named parameters instead of stuffing a dict in args[0]
Replaced the custom, untested memoize with a similar decorator from Python's
3.2 stdlib. Although some minor performance degradation (see ticket), it is
expected that in the long run lru_cache will outperform memoize once it is
implemented in C.
Thanks to EvilDMP for the report and Baptiste Mispelon for the idea of
replacing memoize with lru_cache.
SuspiciousOperations have been differentiated into subclasses, and
are now logged to a 'django.security.*' logger. SuspiciousOperations
that reach django.core.handlers.base.BaseHandler will now return a 400
instead of a 500.
Thanks to tiwoc for the report, and Carl Meyer and Donald Stufft
for review.
