11

I have two identical calls to ASP.NET, the only difference is the User-Agent. I used Fiddler to reproduce the issue.

The HTTP request line is:

PUT http://localhost/API/es/us/havana/club/tickets/JiWOUUMxukGVWwVXQnjgfw%7C%7C214 HTTP/1.1

Works with:

User-Agent: Mozilla/5.0 (Linux; Android 4.3; Nexus 10 Build/JSS15Q) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2307.2 Safari/537.36

Fails with:

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 Mobile/12A4345d Safari/600.1.4

Everything else is 100% the same.

sdabet
  • 18,360
  • 11
  • 89
  • 158
user2105237
  • 485
  • 2
  • 6
  • 11
  • How does it fail? What is the returned status code? Any error trace on server side? – sdabet Nov 13 '15 at 14:28
  • Server Error in '/Api' Application. Illegal characters in path. ArgumentException: Illegal characters in path.] System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional) +13766780 System.IO.Path.GetExtension(String path) +28 System.Web.WebPages.DefaultDisplayMode.TransformPath(String virtualPath, String suffix) +49 System.Web.WebPages.DefaultDisplayMode.GetDisplayInfo(HttpContextBase httpContext, String virtualPath, Func`2 virtualPathExists) +33 System.Web.WebPages.DisplayModeProvider.GetDisplayInfoForVirtualPath(String virtualPath, HttpContextBase,.. – user2105237 Nov 13 '15 at 16:41
  • Let me clarify the issue seems to be unrelated to Fiddler. I just used fiddler to trace the calls. – user2105237 Nov 13 '15 at 16:46
  • Did you check this? https://stackoverflow.com/questions/27487032/user-agent-causes-mvc-displayfor-argumentexception-illegal-characters-in-path – sdabet Nov 13 '15 at 16:47
  • 1
    Hi, it was never getting inside a hook I could find (message handlers, authorization attributes, etc) so I decided to base64 encode the key. It seems that the combination of double pipes (||) and the agent were the problem. The original key was JiWOUUMxukGVWwVXQnjgfw||214 before the http encode. Thanks for your advice.. – user2105237 Nov 18 '15 at 15:36

1 Answers1

7

In my case, the root cause was MVC's MultipleViews and DisplayMode providers. This allows MVC apps to magically pick up device-specific views; e.g. custom.cshtml customer.mobile.cshtml

This article has a good explanation of the functionality as well as details how to turn it off: https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/august/cutting-edge-creating-mobile-optimized-views-in-asp-net-mvc-4-part-2-using-wurfl

I fixed this by adding Microsoft.AspNet.WebPages package to my project and adding a call to this code in my startup (application_start in global.asax or if using OWIN, the method decordated w/ OwinStartup attribute):

public static void RegisterDisplayModes()
{
    // MVC has handy helper to find device-specfic views. Ain't no body got     time for that.
    dynamic modeDesktop = new DefaultDisplayMode("") { ContextCondition = (c => { return true; }) };
    dynamic displayModes = DisplayModeProvider.Instance.Modes;
    displayModes.Clear();
    displayModes.Add(modeDesktop);
}
Frédéric
  • 9,364
  • 3
  • 62
  • 112
Mark Nadig
  • 4,901
  • 4
  • 37
  • 46
  • Looking at `DisplayModeProvider` code, we can simply instantiate the default mode this way: `var modeDesktop = new DefaultDisplayMode();`, it will be functionally identical. By the way, why using dynamics? This kills compilation checks: better use explicit typing or implicit `var` typing. – Frédéric May 29 '22 at 16:26