This proposal is to get rid of that and come up with something better. Solution 1 is to remove the logic that makes the server respond with the content of the target of the redirect and instead respond with a native browser redirect. This means the browser will be told, "nothing here, go to https://en.wikipedia.org/wiki/Foo_events#Foo_2017 instead.". The browser then essentially aborts the load, updates the browser bar, and goes to make another request to the server (transparent to the user). This solves the problem, but does come at the cost of performance. (As user's devices will now sending a request, getting a respond, and then doing the ceremony a second time.)
Jun 29 2017
To clarify: I was talking about the "redirected from" notice, which at least the current description does not call out as needs-to-work-without-JS. While fundamental functionality like linking clearly shouldn't rely on JS, it might make sense to rely on JS for less critical features like small notices aimed primarily at editors, especially when that enables better cache performance.
Jun 28 2017
TLDR: Currently it makes browser to download a result file in application/sparql-results+xml format, which is hard to understand and not what user would expect, IMO.
Jun 27 2017
Could you please explain what the motivation behind this is and also what you expect to work without JS?
Jun 20 2017
Related use cases we don't want to break:
Also performance? A HTTP redirect would introduce delay for no good reason (unless we cache it in Varnish and then deal with cache invalidation).
[...] IMO the low-hanging fruit is to just change the text of the redirect warning as suggested in T53736#556866.
May 30 2017
https://en.wikipedia.org/w/index.php?title=Feh_%28image_viewer%29&action=edit&undoafter=767731611&undo=782915510 produces an error message claiming that an edit conflict exists.
May 29 2017
Several people above have suggested that a client-side solution would be acceptable. I disagree.
As discussed here, another example of this bug is at https://en.wikipedia.org/w/index.php?title=MalwareTech&diff=782456060&oldid=782449642 . In that diff, both the left and right columns have hunks that begin "Following his work on the WannaCry ransomware attack in 2017" and that are almost identical (edit distance: 3) but that have been aligned with other hunks instead of with each other, making it very hard to spot what has changed between them. (To spare you searching, it is "he's" to "he has".)
Nov 22 2016
Sep 8 2016
User 126.96.36.199 has added a note about this issue on my talk page.
Sep 6 2016
here's an edit from 2011 that documents this behavior on the English Wikipedia
If they "are currently broken" and do not work, what does that mean? That you still end up on the correct page, just not scrolling to the correct position?
From the user perspective this would have a similar effect to using 301s. It would make end users end up copying the canonical url instead of the redirect's url.
Sep 5 2016
Jul 24 2016
Can I ask that the fix [...] prevent the shortened URLs containing characters that are ambiguous in common fonts [...]
Yes, that's already implemented. See T139511: Remove 0 and O from the list of characters as they are visually confusing for some more details.
Jul 22 2016
Can I ask that the fix for this feature request implement something like newbase42 (which is abandonware, but the principle is clear) in order to prevent the shortened URLs containing characters that are ambiguous in common fonts, such as these characters: