1

I have an ASP.NET Core web API and an issue with encoded URL's in query parameters.

I have an URL parameter like 'path/to/'. The IDENTIFIER part is something like 'HÄÄ/20/19'. This is urlEncoded in frontend to a link URL. The result is a link like 

domain.com/new/stuff/path/to/H%C3%84%C3%84%2F20%2F19

Now, at some point, user gets redirected to a controller where this URL is used in a query parameter like: 

param=%2Fpath%2Fto%2FH%C3%84%C3%84%2F20%2F19

I'm using request query to get the param

var param = HttpContext.Request.Query["param"].ToString();

After this the value of param is 

%2Fpath%2Fto%2FHÄÄ%2F20%2F19

So the LATIN CAPITAL LETTER A WITH DIAERESIS are automatically decoded as the other encoded characters are not.

The actual problem comes when I'm redirecting the user to this URL. It ends up with a referer header where it causes havoc with an error message

System.InvalidOperationException: Invalid non-ASCII or control character in header: 0x00C4

I tried to just replace all the 'Ä' characters with 'A' and the problem is fixed. This is not a real fix though. I cannot encode the whole variable (see above) as it would result in double encoding for other encoded characters.

This problem only occurs with IE11 and Edge (AFAIK) and works fine with at least Chrome.

I'm not 100% sure where the actual problem is and why this is happening so does anyone have any ideas where to start looking and how to fix this without hacking with the string.replace?

EDIT
I could fix it with something like this, but I'm not seriously doing this. Seems way too hacky. 

var problemPart = param.Substring(param.LastIndexOf('/') + 1, param.Length - param.LastIndexOf('/') - 1);
var fixedPart = WebUtility.UrlDecode(problemPart);
fixedPart = WebUtility.UrlEncode(fixedPart);
param = param.Replace(problemPart, fixedPart);

EDIT 2
I think the problem is that IE11 and Edge change the encoding by adding control characters to it when the URL ends up to the referer header. The fix I added to the original post doesn't actually fix the problem but just work around it. The control character that gets added to the URL is %C2%84 (so Ä becomes %C3%84%C2%84 instead of just %C3%84)

TEMPORARY WORKAROUND
I basically used the code above to workaround the issue. I iterated the parameter value and re-encoded all the invalid characters in it. This doesn't fix the root cause but works around the issue and user doesn't get any errors to the screen.

Antti Simonen
  • 964
  • 1
  • 14
  • 25
  • Can you decode (I would believe Ä will be left alone) and then re-encode again as a workaround? – Pasi Savolainen Mar 21 '18 at 11:44
  • Cannot encode the whole param as it has valid URL components that should not get encoded. The decoding works as you suggested and I could probably use it after I parse the last part of the string out first. Somehow I feel I should not need to do that... – Antti Simonen Mar 21 '18 at 11:55
  • Can you check with Fiddler at which stage the URL gets botched? ie. is it IE/Edge internals or something they set that causes IIS/kestrel to do that. – Pasi Savolainen Mar 21 '18 at 19:53
  • I think the problem is that IE11 and Edge change the encoding by adding control characters to it when the URL ends up to the referer header. The fix I added to the original post doesn't actually fix the problem but just work around it. The control character that gets added to the URL is %C2%84 (so Ä becomes %C3%84%C2%84 instead of just %C3%84) – Antti Simonen Mar 22 '18 at 10:18

0 Answers0