On 22 août, 10:02, Aaron Sokoloski <asokolo...@gmail.com> wrote: > Hmm, that's a tricky issue. If it is set in stone that url parameters are > not unquoted automatically before they hit the view function, that implies > that reverse should not quote automatically.
Do you mean that when a URL is resolved, the view still gets quoted args/kwargs at the moment? If so, it feels to me we should change that. It does not really make much sense to retain the escape characters in a view's parameters. The use of quote/unquote should be consistent everywere. No matter whether these functions really change anything in the specific case where it's used. If reverse does not quote anything, you should always quote it yourself, like here: >> "http://"; + urllib.quote(reverse(...)) + "?param=value" Even if reverse did not output any special character like '?' or '%'. If wrapping reverse into quote is required in some cases, we should do it everywhere before outputting the url into HTML. Not being consistent in escaping is how injection vulnerabilities happen... I think in Django, that one should consider the result of "reverse" as a final url path. Without query string and protocol off course. But still not something where you should do any string operation (like substitution) upon, before passing it to quote. Someone could do the following, which would not work if reverse did automatically quoting, but I consider this bad design. >> reverse('my_page', args=['some-%i-url-slug']) % some_integer Or this, which is a concatenation of a quoted and unquoted string. (Which sounds like bad design to me but can be overcome by wrapping the prefix in quote manually.) >> "/prefix" + reverse('my_page') We should also make a decision about whether the regex in the urlpatterns are written quoted or unquoted. I would say, keep these unquoted for readability. >> url(r'^some-%-url/$', ...) If we have the following patterns: >> url(r'^(?P<param>some-%-url)/$', ...) It should call the view with **{'param': 'some-%-url' } Like Aaron, I can also see no reason for not quoting the reverse call. Cheers, Jonathan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
