#26466: set_language with next unset and a urlencoded HTTP_REFERER fails
redirection
--------------------------------------+------------------------------------
Reporter: miikkas | Owner: miikkas
Type: Bug | Status: assigned
Component: Internationalization | Version: 1.9
Severity: Normal | Resolution:
Keywords: set_language | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Description changed by miikkas:
Old description:
> 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.
>
> 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.
>
> 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.
>
> AFAIK 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.
New description:
POSTing 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.
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 urlencoded, thus resulting in a double
urlencoded URL, which obviously will not work. Non-urlencoded URLs in
HTTP_REFERER work correctly.
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 –
basically the way I found this bug.
AFAIK 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26466#comment:3>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.5d66a5ceb23dd85955b17b5ff4d5806e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
