{"id":1364,"date":"2013-09-03T16:41:00","date_gmt":"2013-09-03T16:41:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/webdev\/2013\/09\/03\/debug-scriptbundle-results-in-404-if-virtualpath-parameter-contains-a-dot\/"},"modified":"2022-08-09T05:48:02","modified_gmt":"2022-08-09T12:48:02","slug":"debug-scriptbundle-results-in-404-if-virtualpath-parameter-contains-a-dot","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/debug-scriptbundle-results-in-404-if-virtualpath-parameter-contains-a-dot\/","title":{"rendered":"Debug ScriptBundle results in 404 if virtualPath parameter contains a dot"},"content":{"rendered":"

I spent some time debuging a ScriptBundle problem last Friday and want to share my experience.<\/span><\/p>\n

The original code in a MVC project App_Start\/BundleConfig.cs<\/em> file:<\/p>\n

\n
\n
Code Snippet<\/div>\n
\n
    \n
  1. bundles.Add(<\/span>new<\/span>ScriptBundle<\/span>(<\/span>“~\/bundles\/jquery.signalR”<\/span>).Include(<\/span><\/li>\n
  2.             “~\/Scripts\/jquery.signalR-{version}.js”<\/span>));<\/span><\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/div>\n

    And in a cshtml file, the bundle is included as:<\/p>\n

    \n
    \n
    Code Snippet<\/div>\n
    \n
      \n
    1. @<\/span>Scripts<\/span>.Render(<\/span>“~\/bundles\/jquery.signalR”<\/span>)<\/span><\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/div>\n

      In local IIS Express debugging mode, I found no problem. So I deployed to Azure to see if project works in real server. And to my surprise, it reported an error that SignalR is not loaded. The following image from the IE F12 developer tools shows a 404 is returned when getting \/bundles\/jquery.signalR<\/em>.<\/p>\n

      \"clip_image001\"<\/a><\/p>\n

      To find out if bundling works locally, I changed project configuration to release, and changed web.config debug<\/span>=<\/span>“<\/span>true<\/span>” <\/span>to debug<\/span>=<\/span>“<\/span>false<\/span>“<\/span>. Then running the site on IIS Express returns the same 404 as well.<\/p>\n

      I did a few searches in Bing. First, I went to MSDN documentation on ScriptBundle<\/a>. Nothing there except I saw the parameter is named as “virtualPath”.<\/p>\n

      Later I found a forum question<\/a> talking about IIS Virtual directory won’t work if it has a dot in the name. I also found a stackoverflow question<\/a> which answer says remove the dot but gave a non-convincing reason. So the solution is to remove the dot from virualPath parameter, and it worked!<\/p>\n

      Further search for reason shows that IIS by default rejected URLs that have dot in path for security reasons. For example, in URLScan.ini downloaded from http:\/\/www.iis.net\/learn\/extensions\/working-with-urlscan\/urlscan-setup<\/a>, it shows:<\/span><\/p>\n

      \n
      \n
      Code Snippet<\/span><\/div>\n
      \n
        \n
      1. AllowDotInPath=0               ; If 1, allow dots that are not file<\/span><\/span><\/li>\n
      2.                                ; extensions. The default is 0. Note that<\/span><\/span><\/li>\n
      3.                                ; setting this property to 1 will make checks<\/span><\/span><\/li>\n
      4.                                ; based on extensions unreliable and is<\/span><\/span><\/li>\n
      5.                                ; therefore not recommended other than for<\/span><\/span><\/li>\n
      6.                                ; testing.<\/span><\/span><\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/div>\n

         <\/p>\n

        In ISA server URLScan.ini documentation<\/a>, it offers more explanation:<\/span><\/p>\n

        \n

        By default, this option is set to 0. If this option is set to 0, URLScan rejects any request that contains multiple periods (.). This prevents attempts to disguise requests for dangerous file name extensions by putting a safe file name extension in the path information or query string portion of the URL. For example, if this option is set to 1, URLScan might permit a request for http:\/\/servername\/BadFile.exe\/SafeFile.htm because it interprets it as a request for an HTML page, when it is actually a request for an executable (.exe) file with the name of an HTML page in the PATH_INFO area. When this option is set to 0, URLScan may also deny requests for directories that contain periods.<\/span><\/p>\n<\/blockquote>\n

        In summary, looks like for all the MVC\/WebAPI routing, don’t put dot in any virtual path to avoid the above problem.<\/p>\n

         <\/p>\n

        Update on 11\/17\/2013:<\/p>\n

        As indicated by my updated answer in stackoverflow question<\/a> later, I found the truth behind the problem:<\/p>\n

        This is caused by the fact that the default MVC routing only handles * instead of * . *, i.e. IIS or IIS Express’s applicationhost.config has the following:<\/p>\n

        <<\/span>add name<\/span>=<\/span>\"ExtensionlessUrl-Integrated-4.0\"<\/span> path<\/span>=<\/span>\"*.\"<\/span> verb<\/span>=<\/span>\"GET,HEAD,POST,DEBUG\"<\/span> type<\/span>=<\/span>\"System.Web.Handlers.TransferRequestHandler\"<\/span> preCondition<\/span>=<\/span>\"integratedMode,runtimeVersionv4.0\"<\/span> responseBufferLimit<\/span>=<\/span>\"0\"<\/span>\/><\/span><\/code><\/pre>\n
        So to workaround it, we can add the following to the web.config:<\/p>\n
            <system.webServer<\/span><\/span><\/span>><\/span><\/span><\/span><\/p>\n
                     <handlers<\/span><\/span><\/span>>      <\/span><\/span><\/span><\/p>\n
                      <add <\/span><\/span><\/span>name<\/span><\/span><\/span>=<\/span><\/span><\/span>“<\/span><\/span>UrlRoutingHandler<\/span><\/span><\/span>“<\/span><\/span>   <\/p>\n
                 type<\/span><\/span><\/span>=<\/span><\/span><\/span>“<\/span><\/span>System.Web.Routing.UrlRoutingHandler, <\/span><\/span><\/span><\/p>\n
                                 System.Web, Version=4.0.0.0,<\/p>\n
                                 Culture=neutral,<\/p>\n
                                 PublicKeyToken=b03f5f7f11d50a3a“<\/span><\/span><\/p>\n
                          path<\/span><\/span><\/span>=<\/span><\/span><\/span>“<\/span><\/span>\/bundles\/*<\/span><\/span><\/span>” <\/span><\/span>verb<\/span><\/span><\/span>=<\/span><\/span><\/span>“<\/span><\/span>GET<\/span><\/span><\/span>“<\/span><\/span>\/>      <\/span><\/span><\/span><\/p>\n
                    <\/handlers<\/span><\/span><\/span>><\/span><\/span><\/span><\/p>\n
                  <\/system.webServer<\/span><\/span><\/span>><\/span><\/span><\/span><\/p>\n
        For more information, you can reference the following:<\/p>\n
        ASP.NET MVC Url Route supporting (dot)<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
        I spent some time debuging a ScriptBundle problem last Friday and want to share my experience. The original code in a MVC project App_Start\/BundleConfig.cs file: Code Snippet bundles.Add(newScriptBundle(“~\/bundles\/jquery.signalR”).Include(             “~\/Scripts\/jquery.signalR-{version}.js”)); And in a cshtml file, the bundle is included as: Code Snippet @Scripts.Render(“~\/bundles\/jquery.signalR”) In local IIS Express debugging mode, I found no problem. So I deployed […]<\/p>\n","protected":false},"author":410,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[197],"tags":[7447,7286,7448,7449],"class_list":["post-1364","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aspnet","tag-bundle","tag-mvc","tag-routing","tag-scriptbundle"],"acf":[],"blog_post_summary":"
        I spent some time debuging a ScriptBundle problem last Friday and want to share my experience. The original code in a MVC project App_Start\/BundleConfig.cs file: Code Snippet bundles.Add(newScriptBundle(“~\/bundles\/jquery.signalR”).Include(             “~\/Scripts\/jquery.signalR-{version}.js”)); And in a cshtml file, the bundle is included as: Code Snippet @Scripts.Render(“~\/bundles\/jquery.signalR”) In local IIS Express debugging mode, I found no problem. So I deployed […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1364","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/410"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=1364"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1364\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=1364"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=1364"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=1364"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
        http:\/\/weblogs.asp.net\/owscott\/archive\/2013\/01\/16\/handing-mvc-paths-with-dots-in-the-path.aspx<\/a><\/p>\n