Requests for comment/Entry point routing and 404 handling
| Entry point routing and 404 handling | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Daniel Friesen |
| Document status | accepted Accept -- Tim Starling (talk) 05:15, 19 July 2013 (UTC) |
Entry Point Routing
editRight now all of our file entry points are isolated. /api.php always does the api, /index.php always does page views, /thumb.php always does thumbnails, /img_auth.php always does private image.
To create a short path for any of these any rewrite you make MUST ensure to point to the correct php file. You cannot simply forward anything that looks like a special path to index.php and have it decide what entry point was intended based on the path that was accessed and the wiki's config.
The proposal here is to convert each of these php file entry points into something that simply forwards to index.php. Our /api.php will simply require index.php, perhaps also set some sort of constant like MW_ENTRY_POINT_PATH for those on webservers that don't like to pass good _SERVER data. Then our WebRequest will determine what the entry point is and from that index.php will run a relevant entry point handler. That is, something that executes the api when the REQUEST_URI was /api.php, and runs the normal path handling on paths like /wiki/, etc...
Adding this will allow extensions to define new entry points as well. For example a ForumExt extension could define a /extensions/ForumExt/forum.php entry point that would simply forward to index.php, this would serve as a fallback for those on servers that can't handle short urls. For those who CAN setup short urls, they can simply include something like /forum/ within the standard set of shorturl paths they send to index.php. And with a little bit of configuration all /forum/ paths will go to ForumExt's entry point instead of to the normal entry point.
The problem with this example in our current situation for the author of ForumExt and users installing it is that /extensions/ForumExt/forum.php and index.php are two completely different entry points. If /forum/ were to be added as a short url then the short url rules would have to special case /forum/ and make sure it gets sent to /extensions/ForumExt/forum.php instead of letting /index.php route everything where it belongs. Depending on the webserver setup the difference in configuration needed to send everything to /index.php and just some paths to a separate .php file can be slightly different, or a whole pile of extra server configuration that shouldn't be necessary.
404 Handling
editRight now if you forward something like /asdf to /index.php our path routing code will not recognize it and will redirect to the wiki's main page. This proposal is to add a 404 special page to MediaWiki.
The special page may function like Extension:Special404 does giving hints like suggesting /wiki/Foo page when a user goes to /foo. Because this will be a part of core this shouldn't need any extra configuration besides an error document setting. MediaWiki's path routing code will detect paths like / and /wiki specifically and treat them as basic paths that should be redirected to the Main Page. While other paths like /asdf will be treated as 404 errors and the 404 special page will be run.
- The Wikisources could make use of a smart 404 message, especially one that could make use of a title search and present a cutdown set of search results for the sought work. This is often the case that a mislink (typos, page moves at source site), a deleted page, or a page in an alternate namespace, where presenting a close option would be of value. Even the ability to allow for some pre-set search criteria that could assist to more readily find pages. — billinghurst sDrewth 12:45, 17 November 2013 (UTC)
Entry point + 404 handling
editAs a result of both of these features being added, we can add native 404 thumbnail handling to MediaWiki. If one sets /index.php to their webserver's error document MediaWiki's path routing code will take this as a 404 and display an error page. However if it instead matches what looks to be a thumb url, we can automatically (without any extra configuration or very verbose rewrite rules) extract the info we want from the path and set thumb.php as the entry point. At that point even though the request went to /index.php we can treat it as a thumbnail handler url.