HTTP triggered functions with reserved names in a route cause 404

[troyhunt]

Consider an HTTP triggered function with a route like this: mypath/{myparam}

Now pass a param to the route that matches one of the reserved names listed here followed by a dot: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file

For example, mypath/con.foo

Calling this route causes Azure to return 404. This doesn't happen when tested locally yet appears consistently in Azure. There's a Twitter thread documenting this here: https://twitter.com/troyhunt/status/1059254759293542400

It's also discussed (and excellently explained!) in a thread from only a couple of days ago here: https://twitter.com/Foone/status/1058676834940776450

The behaviour can be reproduced in a live Azure Function via this URI: https://api.haveibeenpwned.com/unifiedsearch/con.foo@example.com

Substituting the alias of the email address in that path will either return HTTP 200 with a valid JSON body or HTTP 404 with a CORS header returned by the function itself.

Expected behaviour is that the param is successfully passed to the function and not blocked.

[davidebbo]

To fix this, we need to set <httpRuntime relaxedUrlToFileSystemMapping="true"/> in web.config (here). This post explains the behavior: https://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx/.

Note that I would expect this to be a v1 only issue, since v2 uses .NET Core, which should allow this by default.

[fabiocav]

The difference in behavior is likely due to the hosting model differences between local and prod (direct/self-hosted vs IIS/in-proc).

[fabiocav]

Quick PR with @davidebbo's recommended fix here: #3750

[fabiocav]

Resolved by #3750