Changes between Initial Version and Version 3 of Ticket #26466


Ignore:
Timestamp:
Apr 5, 2016, 12:43:35 PM (9 years ago)
Author:
Miikka Salminen
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #26466

    • Property Owner changed from nobody to Miikka Salminen
    • Property Status new → assigned
    • Property Triage Stage Unreviewed → Accepted

  • Ticket #26466 – Description

    initial v3  
    1 POSTing to `set_language` when `next` is not set causes Django to user HTTP_REFERER instead. If the URL in HTTP_REFERER is urlencoded, the resulting redirection will fail.
     1POSTing to `set_language` when `next` is not set causes Django to use HTTP_REFERER instead. If the URL in HTTP_REFERER is urlencoded, the resulting redirection will fail.
    22
    3 The bug is caused by the call to `translate_url` function in `set_language`. `translate_url` passes the URL on to `reverse`, which assumes URLs that are not urlencoding, thus resulting in a double urlencoded URL, which obviously will not work. Non-urlencoded URLs in HTTP_REFERER work correctly.
     3The bug is caused by the call to `translate_url` function in `set_language`. `translate_url` passes the URL on to `reverse`, which assumes URLs that are not urlencoded, thus resulting in a double urlencoded URL, which obviously will not work. Non-urlencoded URLs in HTTP_REFERER work correctly.
    44
    5 An easy way to test this is to have a view with a URL with unicode characters in it and use the translation selector widget provided in the i18n docs, but with the `redirect_to` context variable undefined, which is the way I found the bug.
     5An easy way to test this is to have a view with a URL with unicode characters in it and use the translation selector widget provided in the i18n docs, but with the `redirect_to` context variable undefined – basically the way I found this bug.
    66
    77AFAIK there's no standard about whether the browser should encode the URL in HTTP_REFERER, but most of the new browsers do so anyway. The bug should be easy to fix, thus, by just decoding the string in HTTP_REFERER – if it was encoded, it will now be unencoded, if it was '''not''' encoded, it will be unchanged (disregarding a corner case of ambiguous URLs with substrings like `%C3%A4` verbatim with browsers that don't encode the URLs). I'll make a pull request within a few days.
Back to Top