Microsoft Edge Does Not Load Pages From a Location Header URL with non-ASCII Characters

by Oliver 7. February 2017 02:19

For much too long, this bug annoyed Camping.Info users with Microsoft's Edge browser.

Encoding problem with non-ASCII urls

When redirecting the browser to a URL such as https://www.camping.info/österreich/tirol/camping-sölden-19387 via the Location header, Edge would request this URL from our server: https://www.camping.info/österreich/tirol/camping-sölden-19387 whereas the correctly encoded version of above URL looks like this: http://www.camping.info/%C3%B6sterreich/tirol/camping-s%C3%B6lden-19387.

Here are two bug reports at Microsoft that complain about this exact problem:

EDGE: URLs with Unicode characters do not load and become garbled

EDGE: Does not cope with UTF Location headers

Using a hex editor to look at those weird characters ö I found out that those actually represent the characters with hex value C3 and B6. So, instead of percent encoding the UTF-8 representation of the character ö, Edge would use the UTF-8 hex values for ö to retrieve the given resource. That's surely a bug.

How to fix this behavior

The only viable fix I could come up with was to send Edge an encoded Location header value. Strictly speaking, that is how it should be done anyway but all major browsers including IE have learned to understand and correctly load even unencoded UTF-8 urls. And with IE there was always the problem that a once encoded URL would not be shown in its friendly unencoded version but would stay full of those %AB%CD blocks which look rather ugly.

That's why for a long time, we've been returning unencoded Location header values in redirects.

Well, Edge, you'll get an encoded version then, if you need.

In a central spot, where all of our redirects are handled, we now have this:

var redirectLocation = IsBrokenEdge(app.Request)
    ? Uri.EscapeUriString(sb.ToString())
    : sb.ToString();

And we determine broken Edge version via its build number knowing that at least 14905 contains an official fix:

private Regex _regexEdge = new Regex(@"Edge\/\d+\.(?'build'\d+)", RegexOptions.Compiled);

private bool IsBrokenEdge(HttpRequest request)
{
    var match = _regexEdge.Match(request.UserAgent ?? "");
    if (!match.Success) return false;

    var buildNumber = int.Parse(match.Groups["build"].Value);
            
    // at least, build number 14905 is fixed
    // see: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8477507/
    return buildNumber < 14905;
}

Thanks to http://stackoverflow.com/questions/31223702/how-to-detect-new-microsoft-browser-edge-in-asp-net for some hints on user agent detection for Edge.

End of story.

Happy coding!

Comments (2) -

thor Sweden
4/12/2017 3:36:59 AM #

If someone found their way here from Google(like me), here is a short PHP quickfix-snippet:
if (preg_match("/Edge\/1(2|3|4)\./", getenv('HTTP_USER_AGENT'))) {
    $query = rawurlencode($query);
}

Comments are closed

About Oliver

shades-of-orange.com code blog logo I build web applications using ASP.NET and have a passion for javascript. Enjoy MVC 4 and Orchard CMS, and I do TDD whenever I can. I like clean code. Love to spend time with my wife and our children. My profile on Stack Exchange, a network of free, community-driven Q&A sites

About Anton

shades-of-orange.com code blog logo I'm a software developer at teamaton. I code in C# and work with MVC, Orchard, SpecFlow, Coypu and NHibernate. I enjoy beach volleyball, board games and Coke.