This RFC has been scheduled for public discussion on June 28 (Wednesday) at 21:00 UTC (2pm PDT, 23:00 CEST). As always, the discussion will take place in the IRC channel #wikimedia-office
Currently /wiki/Redirect responds with the Target page, with three notable differences:
- A "Redirected from .." message is rendered.
- Page markup (wikitext) refers to the title as specified. – [[Redirect]] is saved as-is, no pre-save transformation)
- Page rendering refers to the title as specified – HTML: <a href="/wiki/Redirect">
- When clicking on such link within the wiki, or otherwise navigating "to" the redirect, the server responds with a modified version of the response for the target of the redirect. – /wiki/Redirect responds the same as /wiki/Target, including a <link rel=canonical> specifying Target as canonical, and a special header informing the reader "Redirected from Redirect".
- Jump to the intended section (if any).
- Swap the address bar from /wiki/Redirect to /wiki/Target. This encourages further social sharing to share the canonical link, and makes it so that those other people will not needlessly see "Redirected from Redirect" - which doesn't apply to those readers.
- Parser cache: Changing the redirect does not require invalidating parser cache of incoming links.
- Performance: "Following" a redirect responds quickly (no HTTP redirect).
- Usability: Users know when they followed a redirect (header message "Redirected from"), and the message doesn't show for others when you share the link.
- Search engines: No indexing of duplicate content. (due to canonical url).
- Fallback: In our Grade C experience for older (but supported) browsers, the jump never happens.
- Fallback: It also means that on supported browsers, the jump doesn't happen if there were intermittent connection issues.
- Fallback: There is no recovery for the user when the jump doesn't happen. There is no manual way to get to this information (it's hidden in invisible JSON data)
Change the response of /wiki/Redirect to be an HTTP redirect to /wiki/Target?rdfrom=Redirect#Section. When viewing /wiki/Target?rdfrom=Redirect#Section, client-side code normalises the address bar to /wiki/Target#Section.
This addresses all the problems.
- Drawback: Users will be subject to an HTTP redirect.
- Benefit (compared to Solution 2): Redirects are instantly up-to-date (no need to wait for job queue).
Same as solution 1, but in addition, optimise the common case by changing the Parser to resolve to this url ahead of time.
- Benefit: Faster user experience for the common case.
- Drawback: Updating of urls depends on job queue, similar to template transclusion updates.