You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just experienced a weird bug with the Twitter Mac app, where a URL with a hash in it (https://craftcms.com/knowledge-base/configuring-load-balanced-environments#mutex-locks) was getting its hash mark encoded to %23:
I figured it would be easy enough to add a redirect for that in Retour, however Retour ended up decoding the %23 to #, and then didn’t like how the redirect URL looked identical to the URL pattern, saying it would create an infinite redirect loop.
I ended up working around it by setting the Match Type to regex, and the URL pattern to:
Ideally Retour would not be decoding the %23 – if that’s even possible? – and also should not be rejecting matching URL patterns/destination URLs if the pattern contains a #, since the hash would never get sent to the server in the first place.
To reproduce
Go to Retour → Redirects and create a new redirect
Enter /foo%23bar as the URL pattern
Enter /foo#bar as the destination URL
Press Save
Expected behaviour
The redirect should save, with the URL pattern unmodified, and no warnings about redirect loops.
Versions
Plugin version: 3.1.69
Craft version: 3.7.27
The text was updated successfully, but these errors were encountered:
Describe the bug
Just experienced a weird bug with the Twitter Mac app, where a URL with a hash in it (
https://craftcms.com/knowledge-base/configuring-load-balanced-environments#mutex-locks
) was getting its hash mark encoded to%23
:I figured it would be easy enough to add a redirect for that in Retour, however Retour ended up decoding the
%23
to#
, and then didn’t like how the redirect URL looked identical to the URL pattern, saying it would create an infinite redirect loop.I ended up working around it by setting the Match Type to regex, and the URL pattern to:
Ideally Retour would not be decoding the
%23
– if that’s even possible? – and also should not be rejecting matching URL patterns/destination URLs if the pattern contains a#
, since the hash would never get sent to the server in the first place.To reproduce
/foo%23bar
as the URL pattern/foo#bar
as the destination URLExpected behaviour
The redirect should save, with the URL pattern unmodified, and no warnings about redirect loops.
Versions
The text was updated successfully, but these errors were encountered: