Last modified: 2011-05-06 06:50:04 UTC
The function wfMakeUrlIndex() in includes/GlobalFunctions.php throws an error if passed a file URI that has more than two slashes after "file://". PHP Notice: Undefined index: host in <path>/w/includes/GlobalFunctions.php on line 2636 This is because PHP's parse_url() function handles file URIs differently depending on the number of slashes after "file:". If you have two slashes, you get a 'host' array element: print_r(parse_url('file:///whatever/you/like.txt')); Array ( [scheme] => file [host] => whatever [path] => /you/like.txt ) but with three or more slashes, you don't: print_r(parse_url('file:///whatever/you/like.txt')); Array ( [scheme] => file [path] => /whatever/you/like.txt ) This screws up all references to $bits['host'] in wfMakeUrlIndex. I believe wfMakeUrlIndex() should handle file URIs specially, just as it does "mailto" URIs today. It should accept ANY number of slashes after "file:", because both IE and Firefox today accept these URIs (e.g., representing Windows network shares).
This code is old. It definitely behaves this way in MediaWiki 1.16.4, and the code looks unchanged in 1.18-svn, so I filed it as 1.18-svn.
Argh, I have typos in my code examples. (Wish I could edit them!) The first example, where you have two slashes, should read: If you have two slashes, you get a 'host' array element: print_r(parse_url('file://whatever/you/like.txt')); Array ( [scheme] => file [host] => whatever [path] => /you/like.txt )
Alternatively, you should just check for the existence of $bits['host'] before referencing it, and take some corrective action, eliminating the PHP Notice message.
patches welcome.
I would be happy to patch, but I am missing some domain knowledge. In the externallinks table, what should the el_index column contain for a file:// URI? The current code produces a weird-looking result. For the file link: file:///mywindowsshare.net/foo/bar/blat.xls it creates an el_index value of: file://./mywindowsshare.net/foo/bar/blat.xls I have no clue if this is right or wrong....
If i recall: file:///foo/bar.txt (3 slashes) means the file foo/bar.txt on the current host, where 2 slashes - file://whatever/foo.txt means the file foo.txt on the host named whatever. So php's behaviour is kind of right... However our behaviour is definitely still wrong
Reiterating something above: If you fix this, be sure not to limit yourself to 3 slashes. File URI's with many slashes, such as file://///myshare/foo/bar.txt, should be considered correct too. The major browsers accept them, and in fact, sometimes require them in odd cases.
Committed fix to trunk in r86897. Includes some test cases in the GlobalTest chunk of the phpunit tests. Change checks if 'host' is present and slips in just '.' if not. (Or should we use localhost? Technically not the same... sorta. :) This handles file:///path/foo, file:///c:/path/foo, and file://server/path/foo reasonably well. Multi-slash cases (file://///share/foo) aren't normalized to match the expected more canonical forms (file://share/foo) but they'll go through without error. The lack of consistency between browsers and OSs, and many browsers keeping file: urls disabled for HTTP pages, means we probably can expect folks to be using the IE/Windows style for most actual cases of intranet use.
*Bulk BZ change: -bugsmash from closed bugs. (7 Bugs)*
