CODEWITHSUNDEEP
c#asp.netiis
Dan7el
Dan7el

Reputation: 2047

IIS 8.5 File Path Not Found -- URL Encoded

Windows Server 2012 R2

IIS 8.5

.NET Framework 4.5.1 installed with Windows 8.1 or Windows Server 2012 R2

ASP .NET App written in C# in Visual Studio 2012

This is an issue that has only recently started to occur in an application that has been running on an older operating system (I believe IIS 7.5 Windows 2008R2 but not 100% sure).

Essentially, when the application builds a path to a file on the local system, it URL encodes the path. Then, when the application attempts to find said file, it returns File Not Found.

The code itself is a tad silly. I didn't write it and I plan to re-write it when time permits. Here is the method that attempts to grab the file and display it on the screen:

private void OpenClaimFile(String PackageId, String ClaimId, String DocType, String AttachmentID)
{
    string filename = string.Empty;

    string folderPath = Helper.PackagePath + PackageId + @"\" + ClaimId + @"\";
    string path = string.Empty;


    if (string.IsNullOrEmpty(DocType) || DocType == " ")
    {
        filename = AttachmentID;
    }
    else
    {
        filename = DocType + "_" + AttachmentID;
    }

    path = folderPath + filename + ".pdf";

    if (File.Exists(path))
    {
        Response.Clear();
        Response.AddHeader("content-disposition", "attachment;filename=" + filename);
        Response.ContentType = "application/pdf";
        Response.WriteFile(Helper.PackagePath + PackageId + "/" + ClaimId + "/" + filename + ".pdf");       
    }
    else
    {
        Alert("File Not Found!");
    }
}

Helper.PackagePath is grabbed from the web.config and is something like "D:\RootPath\"

I tested a file without spaces, and the file is downloaded by the browser to the Downloads folder. This is a secondary issue because it should be displayed as a PDF within the browser itself.

Using the SysInternals ProcessMon, I found that the actual file name in the Path string is something like D:\RootPath\PackageID\ClaimID\My%20Mos%20Excellent%20File.pdf rather than D:\RootPath\PackageID\ClaimID\My Most Excellent File.pdf.

The problem appears to be that the application is now URL encoding the path that it builds and then attempting to find that file and failing. I have searched the web for any information about this and my results are next to nothing. I did find this one article.

Tonight if I get a chance, I will attempt to try the change referenced in the article I found to the web.config and see if it solves the problem. For reference, this change is:

<configuration>
    <appSettings>
        <add key="aspnet:UseLegacyRequestUrlGeneration" value="true" />
    </appSettings>

However, I'd appreciate any insight into this issue that anyone has.

Also, if anyone has any insight into my secondary issue, I'd appreciate that. I've only begun to look at it, but the browser should open the file in-situ and not download it. This behavior is also recent. I'm getting the idea that this is a new security setting in the system that forbids opening PDF's because they might be dangerous. I've not fully researched that issue yet, though.

Upvotes: 1

Views: 994

Answers (1)

Dan7el
Dan7el

Reputation: 2047

Using <add key="aspnet:UseLegacyRequestUrlGeneration" value="true" /> did not resolve this issue.

I ended up having to re-write the method to use HttpUtility.UrlDecode(...) on the path. When I did that and also added the "inline" to the Content-Disposition and that solved the PDF view vs download issue.

Upvotes: 1

Related Questions