--- Comment #2 from Lisa Ridley <> 2010-03-03 08:36:40 UTC ---
A possible fix for this issue is as follows:

Change the global function wfUrlencode() to the following:

function wfUrlencode( $s ) {
    $s = urlencode( $s );
        $s = str_ireplace(
        array( '%3B','%3A','%40','%24','%21','%2A','%28','%29','%2C','%2F' ),
        array(   ';',  ':',  '@',  '$',  '!',  '*',  '(',  ')',  ',',  '/' ),

    ## check to see if server is running Microsoft IIS 7 or greater; if so
converts colons back to url encoded values
    if(isset($_SERVER['SERVER_SOFTWARE'])) {
        $server = explode("/", $_SERVER['SERVER_SOFTWARE']);
        if($server[0] == "Microsoft-IIS" &&
($server[1]=='7'||$server[1]=='7.5')) {
            if(!(strpos($s, '%')===false)) {
                $s = str_ireplace(array(':'), array('%3A'), $s);
    return $s;

I have tested this a preliminarily it appears to hae some promise.  I want to
make sure that IIS always sets a value for $_SERVER['SERVER_SOFTWARE'] before
creating a patch and/or modifying trunk.

Another option would be to exclude colons from the str_ireplace() process in
wfUrlencode() for all browsers; however, this would result in an encoded
character for the colon in every instance, which is probably not a desired
behavior since this really only comes into play when there are special
characters in the title prefix.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to