#9921: request.urlconf incorrect behavoir
----------------------------------------+-----------------------------------
Reporter: strelnikovdmitrij | Owner: nobody
Status: reopened | Milestone:
Component: Core framework | Version: 1.0
Resolution: | Keywords: request.urlconf
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 1
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Comment (by kmtracey):
I do not see how changing from using boolean to arithmetic/bitwise "AND"
(but not "NOT") in code where we are dealing with boolean values could
possibly be correct.
Given the precedence
(http://docs.python.org/reference/expressions.html#summary) of boolean
"AND" and "NOT", the code as written today is saying:
if (the path we have been asked to locate is not resolvable) and (adding a
slash to the end it makes it resolvable) then (proceed with settings
things up so we'll do a redirect to the added-slash version of the url)
When you change the boolean "AND" to a bitwise one, but leave the boolean
"NOT", the precedence changes (bitwise "AND" has higher precedence than
boolean "NOT") and the code then says:
if not ("the path as given is resolvable" and "adding a slash to the end
makes it resolvable") then (proceed with settings things up so we'll do a
redirect to the added-slash version of the url)
which means that any not-resolvable-as-originally-specified path will get
redirected to the added-slash version, which is incorrect. We only want
to do the redirect when adding the slash actually results in a resolvable
url.
I'm not re-closing as a dupe, because I'm not sure what it's supposed to
be a dupe of. reverse() is not involved here. I do see there are two
other tickets (#3530 and #5034) with other cases where `request.urlconf`
is not being taken into account when it should be. James tried to get
those consolidated into one but that doesn't seem to have stuck. It does
seem like we have a general problem with `request.urlconf` not being
considered in all the places it should be, and it would be good if they
were all found and fixed together rather than piecemeal (higher likelihood
of doing it in a consistent fashion), but I don't really know enough about
the code involved here to say whether one consistent fix is a reasonable
goal or if these really all need to be fixed individually as they are
tripped over.
--
Ticket URL: <http://code.djangoproject.com/ticket/9921#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
