File Download Functionality Different on Dev and Test Servers

[Rhys666]

I have some file download functionality in an application I'm currently working on which works splendidly on my local machine in development, but functions very differemtly when running n the test seb server.

Basically I have a link that opens my download page and the querystring identifies the type of 'template' Excel spreadsheet has asked to download. The download page reads the querystring, identifies the template required then uses Response.AppendHeader to amend the response to create the file download dialogue. On my local machine this works fine and the download dialogue correctly identifies the file name and type attempting to be downloaded. However, when this is ported to the Test web server the download dialogue asks if I want to save or open the Download.aspx page, not the xls file that should be targetted. To further confuse me, if you save this file, open it in a text editor, remove the html elements of it, leave the encoded elements, (square blocks, hex etc.), and save this as an xls file from the text editor MS Excel opens the saved file correctly and it is in fact the file that was attempted to be downloaded.

To me it appears that on my dev machine the download works fine and streams the excel file to be saved locally, but on the test server it's streaming both the page and the Excel file for downloading. I've included the basics of the code below and was wondering if anyone has a way to explain this behaviour and how to fix it...

private void Page_Load(object sender, System.EventArgs e)
{
    if( Request.QueryString["filetype"] != null )
    {
        // A file download has been requested
        string downloadType = Request.QueryString["filetype"].ToString().ToUpper();
        if( downloadType == FRSessionParameterName.DownloadSRPTemplate.ToUpper() )
        {
            string filePath = ConfigurationSettings.AppSettings["templatesDir"] + 
                "/" + 
                ConfigurationSettings.AppSettings["stormReturnPeriodsDir"] + 
                "/" + 
                ConfigurationSettings.AppSettings["stormReturnPeriodsTemplate"];
                filePath = this.MapPath( filePath ); 
                DownloadFile( filePath, true );
        }
        else
        {
            // Unknown file type - shouldn't happen
        }
    }
}

private void DownloadFile( string path, bool forceDownload ) 
{ 
    string name = Path.GetFileName( path ); 
    string ext = Path.GetExtension( path ); 
    string type = ""; 

    // set known types based on file extension            
    if ( ext != null ) 
    { 
        switch( ext.ToLower() ) 
        { 
            case ".htm": 
            case ".html": 
                type = "text/HTML"; 
                break; 
            case ".doc": 
            case ".rtf": 
                type = "Application/msword"; 
                break; 
            case ".xls": 
                type = "Application/vnd.ms-excel"; 
                break; 
            default:
                type = "text/plain"; 
                break; 
        } 
    } 
    if ( forceDownload ) 
    { 
        Response.AppendHeader( "content-disposition", "attachment; filename=" + name ); 
    } 

    if ( type != "" )
    {
        Response.ContentType = type; 
    }

    // Force file to download
    Response.WriteFile(path); 
    Response.End();
}

Rhys

""Vampireware /n/, a project, capable of sucking the lifeblood out of anyone unfortunate enough to be assigned to it, which never actually sees the light of day, but nonetheless refuses to die."

My Home

 

[ca8msm]

Rhys,

I usually set the ContentType to "application/octet-stream" then it simply forces the save/open dialog regardless of file type. I'm not sure what is going on with yours but here's what I use (although it's in VB.NET) so you could try using this instead:

    Private Sub DownloadFile(ByVal virtualPath As String)
        ' retrieve the physical path of the file to download, and create
        ' a FileInfo object to read its properties
        Dim FilePath As String = Server.MapPath(virtualPath)
        Dim TargetFile As New System.IO.FileInfo(FilePath)

        ' clear the current output content from the buffer
        Response.Clear()
        Response.CacheControl = "Private"
        ' add the header that specifies the default filename for the Download/
        ' SaveAs dialog
        Response.AddHeader("Content-Disposition", "attachment; filename=" + _
            TargetFile.Name)
        ' add the header that specifies the file size, so that the browser
        ' can show the download progress
        Response.AddHeader("Content-Length", TargetFile.Length.ToString())
        ' specify that the response is a stream that cannot be read by the
        ' client and must be downloaded
        Response.ContentType = "application/octet-stream"
        ' send the file stream to the client
        Response.WriteFile(TargetFile.FullName)
        ' stop the execution of this page
        Response.End()
    End Sub

--------------------------------------------------------------------------------------------------------------------------------------------

Need help finding an answer?

Try the search facility (

http://www.tek-tips.com/search.cfm)

or read FAQ222-2244 on how to get better results.

 

[Rhys666]

Tried using some of the techniques suggested in your code but to no avail. Essentially the behavious I'm experiencing is exactly as described in this MS kb article; FIX: Content-Disposition Attachment Header Does Not Save File

The only problem is I'm not using IE 5.5 as the article suggests it applies to and the behavious is not encountered on mine or my co-workers dev machines. The only thing I can think of now is to compare the OS/IIS etc on the test web server and our dev machines, see if I can get the test server set up to allow debugging and step through the code where we experience the problem to see what's happening under the hood.

Darn annoying this, darn annoying

Rhys

""Vampireware /n/, a project, capable of sucking the lifeblood out of anyone unfortunate enough to be assigned to it, which never actually sees the light of day, but nonetheless refuses to die."

My Home