Just recently I came across an issue with file view/download with DNN.

It all started when I added iWork file extension (.key, .pages and .numbers). From my understanding, these extensions are Apples fancy way of packaging content in a zip file with custom extension.

I have been trying to troubleshoot this issue for two days now at first thinking this is an issue with IIS. So, long story short I managed to narrow down the problem to file extension length. To be precise to char length of 4. So, if I trim extension to .page or .numb DNN can serve those files with no issues. Obviously .key being only three chars long doesn't have the same issue.

Now I am looking for anything inside DNN that could be responsible for limiting or filtering request based on file extension length. Help in this matter is greatly appreciated.

To help with troubleshooting the issue:

• I am using DNN v7.4.2 running on IIS 7.5.
• I added .key, .pages, .numbers to the list of Allowable File Extensions in HostSettings.
• I added following MIME maps to IIS:
  • .key
    • application/x-iwork-keynote-sffkey
  • .pages
    • application/x-iwork-pages-sffpages
  • .numbers
    • application/x-iwork-numbers-sffnumbers
• Using DAM to upload and download files i get the following results:
  • No issues downloading (default behavior) keynote files
  • 404 error for pages and numbers
  • No issues with .page or .numb files
• I know is said DAM above but the issue is not limited to DAM. Journal and a few other modules all display the same issue.

Removed: double post - this module needs a fix

Update

I found what limits files extensions to four chars. To find the answer one needs to go digging in ProcessRequest method found in AdvancedUrlRewriter.cs. Close to the very end of try-catch-finally block we have the following:

    if (result.DoRewrite == false && result.CanRewrite != StateBoolean.False && !finished && result.Action == ActionType.Continue)
    // result.DoRewrite = false
    // result.CanRewrite = NotSet
    // finished = false
    // result.Action = Continue
    {
        ...
        //if (!pathWithNoQs.Substring(pathWithNoQs.Length - 5, 5).Contains("."))
        if (!pathWithNoQs.Substring(pathWithNoQs.Length - 5, 5).Contains(".") && !pathWithNoQs.EndsWith(".pages") && !pathWithNoQs.EndsWith(".numbers"))
        {
            ....
        }
    }

Bumping the numbers to 8 or being a bit more specific satisfies this checkpoint and voila I get a prompt to save the files.

However, that still doesn't answer why the same issue doesn't affect three other instances of DNN that I have locally.

Something else worth noting

In web.config if I change friendlyUrl node and set urlForms="humanfriendly" instead of "advanced" the files get served without the adjustment to the core. But it breaks all custom navigation on the site. In addition you you're suing social login providers and I do (namely Azure and Google) I would have to change return url otherwise the users don't get returned back to the site when they try to sing in. And lastly you also get explicit /Default.aspx at the end of each url that doesn't end with .aspx.