Bug 31504 - URL decoding is broken for % characters
Summary: URL decoding is broken for % characters
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 4.2.0 (C6)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Future Release
Assignee: Bugzilla
Depends on:
Reported: 2015-06-30 14:04 UTC by Anton
Modified: 2018-01-05 13:26 UTC (History)
5 users (show)

Tags: bugpool-archive
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Anton 2015-06-30 14:04:42 UTC
The server returns Headers["Location"] like '/some/url/encodedpart%2F100%2F200'


var response = (HttpWebResponse)request.GetResponse()) 

//returns "/some/url/encodedpart%2F100%2F200" on Mac and "/some/url/encodedpart/100/200" on Windows when program compiled on Mac.
//but the same code returns "/some/url/encodedpart%2F100%2F200" on both systems when compiled with VS on Windows.
var location = response.Headers["Location"];


using latest MDK from Xamarin Sdutio / Mono .NET 4.5 target framework
mono -V
Mono JIT compiler version 4.0.2 ((detached/c99aa0c Thu Jun 11 18:53:01 EDT 2015)
Comment 1 Marek Safar 2015-07-01 11:57:50 UTC
I cannot reproduce the issue. Please provide complete test case. I use

var c = new HttpClient ();
var resp = await c.GetAsync ("http://httpbin.org/response-headers?Location=/some/url/encodedpart%2F100%2F200");
Console.WriteLine (resp.Headers);

which returns expected

Server: nginx
Date: Wed, 01 Jul 2015 15:57:31 GMT
Connection: keep-alive
Location: /some/url/encodedpart/100/200
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Comment 2 Anton 2015-07-01 12:22:30 UTC
Yep, but in your example location already decoded. i'm talking about situation where location header looks exactly like this "/some/url/encodedpart%2F100%2F200" 
and Console.WriteLine (response.Headers["Location"]) will print the same string, except the situation described above.

ok, i will try to write test
Comment 3 Anton 2015-07-01 14:41:34 UTC
Sorry, the bug is not in related to request headers, it's somewhere before

1)i'm loading login page using HttpWebRequest
2)parsing html form
3)sending post request

so the input field "redirect_url" after step 1 is differed in the case described above, program compiled in VS works fine in both os, but mono version on windows returns html with wrong value. Trying to reproduce in demo app
Comment 4 Anton 2015-07-01 15:25:28 UTC
Got it:

var request = WebRequest.Create("http://localhost/some/url/encodedpart%2F100%2F200");

Mono version:
OSX: /some/url/encodedpart%2F100%2F200
Win: /some/url/encodedpart/100/200

Win version:
OSX: /some/url/encodedpart%2F100%2F200
Win: /some/url/encodedpart%2F100%2F200
Comment 5 Anton 2015-07-02 20:52:33 UTC
Huh, now i cannot reproduce the issue with XamarinStudio or "xbuild /p:Configuration=Debug LocationTest.csproj" but still have a bug with "mcs Program.cs". magic ;)

Marek Safar, can you reproduce it?
Comment 6 Anton 2015-07-02 21:24:07 UTC
figured out the issue with XamarinStudio, can reproduce when toggle "Run on external console" and build without clean or rebuild.
Comment 7 Anton 2015-07-02 22:19:16 UTC
as far as i figured out the bug is in .net framework versions below 4.5, and the real issue is that the binary built without targeting .net 4.5 after toggling options. as well as without "Use MSBuild build engine" option in any case.

not critical, I'll just clean&build my project.. anyway, thanks ;)
Comment 8 Marek Safar 2015-07-09 15:42:24 UTC
That's correct .net 4.5 uri has set of breaking changes in Uri class. More can be found at https://msdn.microsoft.com/en-us/library/hh367887.aspx#core
Comment 9 Anton 2015-11-19 09:47:29 UTC
Same issue even without changing settings.

how to reproduce:

1)create new console application
2)paste code:

var request = WebRequest.Create("http://localhost/some/url/encodedpart%2F100%2F200");

3)build, copy exe to windows, run. output: /some/url/encodedpart%2F100%2F200
4)make some changes. e.g. copy&paste Console.ReadLine();
5)build, copy exe to windows, run. output: /some/url/encodedpart/100/200

Tested on latest stable versions:
Xamarin Studio Version 5.10 (build 871)
Mono 4.2.1 (explicit/6dd2d0d)
Comment 10 Marek Safar 2015-12-14 14:55:53 UTC
This is another Uri parser bug.

var uu = new Uri("http://localhost/some/url/encodedpart%2F100%2F200");
var au = uu.AbsoluteUri;
Console.WriteLine (au);

Prints /some/url/encodedpart/100/200 on .net

Marcos, I think we should seriously consider replacing Uri code with reference source one
Comment 12 Katelyn Gadd 2017-11-16 11:31:50 UTC
From my testing, we now match Windows .NET 4.5's behavior here and everything looks correct. The MONO_URI_IRIPARSING environment variable was added in the past to opt-in to old 3.5-era parsing behavior for applications that still need it, but everything else should get the right behavior by default (regardless of what target framework the executable was compiled against).