#18210: Regression and crash with any "special" prefix values passed to 
reverse()
---------------------------------+------------------------------------
     Reporter:  toofishes        |                    Owner:  nobody
         Type:  Bug              |                   Status:  new
    Component:  Core (URLs)      |                  Version:  1.4
     Severity:  Release blocker  |               Resolution:
     Keywords:  reverse          |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------

Comment (by gabrielhurley):

 A few things:

   1. Pull request to fix this here:
 https://github.com/django/django/pull/490

   2. While I agree this was a regression and that the exceptions have to
 be fixed, I believe the 1.3-era output (which your attached tests reflect)
 is also wrong for cases 2 and 3. The first case with the curly braces
 escaped is the correct behavior, and the other two cases should reflect
 the URLs with the special characters escaped as well. The tests in the
 pull request reflect that.

   3. Normally the `prefix` argument to reverse is used internally to
 handle namespaces `include`d within one another wherein it'd be very hard
 to get special regex characters into that prefix. That doesn't mean this
 isn't an issue, only that it's an uncommon (and in fact undocumented)
 thing to do. In the internal case the value of prefix is always processed
 by `normalize` before being passed in and has to have originated from a
 valid regex anyhow.

   3. The intention of the quote "Since most people don't have regex
 special characters in the prefix to namespaced urls, it wasn't a problem"
 in the original context was to say that the bug reported in #15900 hadn't
 been discovered because nesting captured groups via multiple namespace-
 included URLconfs was uncommon. Those captured groups were the "regex
 special characters" in question and they weren't being treated as part of
 the regex URL pattern at all. This issue is effectively the reverse of
 that one where unintended special characters are being treated as part of
 the regex (caveat see point #2).

-- 
Ticket URL: <https://code.djangoproject.com/ticket/18210#comment:4>
Django <https://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 django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to