Steps to reproduce the issue

Install JOOMLA on APACHE on a Windows Server environment. Favicons cannot be loaded due to a path issue in /libraries/joomla/document/html/html.php

Expected result

Favicon.ico should be loaded and no error message should appear in APACHE error log.

Actual result

Apache not being able to load the favicon.ico and producing a respective error message in the Apache error log:

[Tue Jul 29 09:44:51 2014] [error] client xxxThe given path was above the root path: Cannot map GET /C:/Webserver/httpdocs/xxxx/templates/jsn_metro_pro/favicon.ico HTTP/1.1 to file
[Tue Jul 29 10:54:13 2014] [error] client xxxThe given path is misformatted or contained invalid characters: Cannot map GET /administrator/C:/Webserver/httpdocs/xxx/administrator/templates/isis/favicon.ico HTTP/1.1 to file

System information (as much as possible)

Additional comments

When installing Joomla on Apache in a MS Windows environment, Favicon.ico cannot be loaded due to a bug in /libraries/joomla/document/html/html.php (code line 575 ff) when rendering the page.

    // Try to find a favicon by checking the template and root folder
    $path = $directory . '/';
    $dirs = array($path, JPATH_BASE . '/');
    foreach ($dirs as $dir)
    {
        $icon = $dir . 'favicon.ico';
        if (file_exists($icon))
        {
            $path = str_replace(JPATH_BASE . '/', '', $dir);
            $path = str_replace('\\', '/', $path);
            $this->addFavicon(JUri::base(true) . '/' . $path . 'favicon.ico');
            break;
        }
    }

Adding the '/' in these statements results in an unsuccessful STR_REPLACE command.
The codeline

$path = str_replace(JPATH_BASE . '/', '', $dir);

actually removes JPATH_BASE plus / from the $dir variable, if the former exists in the latter. However, on windows systems (at least on mine), the $dir variable contains: C:\Webserver\httpdocs\xxx\administrator\ (please note the last backslash, that will be compared to a slash in the str_replace) - so this str_replace NEVER succeeds (this is why the C:/Webserver survives the str_replace).

Using DIRECTORY_SEPARATOR here solves the issue.