Another day, another small learning.
I have been extending ASP.NET Core REST API service that returns redirect (HTTP 301) results for a query. I would submit something like /redirect/A10293 and it would look up the associated SharePoint library URL for that entity.
/redirect/A10293 would then be redirected to https://sharepoint/site/library.
The customer wanted to add another piece of input, to be passed as a parameter of type string: the description of the entity. In SharePoint I had made a SPFx application customizer extension that showed this information in the header.
The new flow would be:
/redirect/A10293?name=Hello%20World should return a redirect to https://sharepoint/site/library?name=Hello%20World.
In testing, we found out that for some entity names the service would return a Server error (HTTP 500). In particular, for the names with strange characters in the name, such as German umlauts like Müller.
/redirect/A10293?name=Hello%20Herr%20M%C3%BCller would fail with a 500.
Thanks to my colleague Christoph König (yes, with umlaut in the surname).
The cause of the error is that HTTP redirects are restricted to ASCII characters in the redirect result, as per the RFC.
In the code I was constructing a string and adding the name parameter as a string. It was being automatically URL-decoded by ASP.NET, and the redirection URL was then something like https://sharepoint/site/library?name=Hello Herr Müller. This tripped the redirect ActionResult parser to raise an exception.
System.Uri class to parse the string and return its AbsoluteUri property. A string, with the canonical, encoded version safe to be used in redirect result.
string redirectUrl = " https://sharepoint/site/library?name=Hello Herr Müller "; Uri redirectURI = new Uri(redirectUrl); return RedirectPermanent(redirectURI.AbsoluteUri);