Response Header issue on Azure Web Application

Question

I am not sure what is happening here.

When I run my web application locally and click a button to download a file, the file is downloaded fine and Response header as you can see in the attached screenshot where it says local.

But when I publish the application to azure web app. Somehow the download button stops working. I checked the Response Header and you can see the difference.

What would cause this problem? The code is the same? Is there any settings that I should be setting in azure web app in azure portal?

Updated to add code

I have debugged remotely to figure out what is going on as @Amor suggested.

It is so strange that When I debug on my local machine first ExportTo action gets hit which prepares the TempData then Download action gets called once the first action completed with ajax call.

However, this is not the case when I debug remotely. Somehow the ExportTo action never gets called. It directly calls the Download action. As a result the TempData null checking is always null.

But why? Why on earth and how that is possible? Is there something cached somewhere?

I have wiped the content of web application on the remote and re-publish evertyhing to ensure everything is updated. But still no success.

here is the code:

[HttpPost]
    public virtual ActionResult ExportTo(SearchVm searchVm)
    {
        var data = _companyService.GetCompanieBySearchTerm(searchVm).Take(150).ToList();

        string handle = Guid.NewGuid().ToString();
        TempData[handle] = data;
        var fileName = $"C-{handle}.xlsx";
        var locationUrl = Url.Action("Download", new { fileGuid = handle, fileName });

        var downloadUrl = Url.Action("Download");

        return Json(new { success = true, locationUrl, guid = handle, downloadUrl }, JsonRequestBehavior.AllowGet);

    }

        [HttpGet]
    public ActionResult Download(string fileGuid, string fileName)
    {
        if (TempData[fileGuid] != null)
        {
            var fileNameSafe = $"C-{fileGuid}.xlsx";
            var data = TempData[fileGuid] as List<Company>;

            using (MemoryStream ms = new MemoryStream())
            {
                GridViewExtension.WriteXlsx(GetGridSettings(fileNameSafe), data, ms);
                MVCxSpreadsheet mySpreadsheet = new MVCxSpreadsheet();
                ms.Position = 0;
                mySpreadsheet.Open("myDoc", DocumentFormat.Xlsx, () =>
                {
                    return ms;
                });
                mySpreadsheet.Document.Worksheets.Insert(0);
                var image = Server.MapPath("~/images/logo.png");
                var worksheet = mySpreadsheet.Document.Worksheets[0];
                worksheet.Name = "Logo";
                worksheet.Pictures.AddPicture(image, worksheet.Cells[0, 0]);
                byte[] result = mySpreadsheet.SaveCopy(DocumentFormat.Xlsx);
                DocumentManager.CloseDocument("myDoc");
                Response.Clear();

                //Response.AppendHeader("Set-Cookie", "fileDownload=true; path=/");
                Response.ContentType = "application/force-download";
                Response.AddHeader("content-disposition", $"attachment; filename={fileNameSafe}");
                Response.BinaryWrite(result);
                Response.End();
            }
        }

        return new EmptyResult();
    }

here is the javascript:

var exportData = function (urlExport) {
    console.log('Export to link  in searchController: ' + urlExport);
    ExportButton.SetEnabled(false);
    var objData = new Object();
    var filterData = companyFilterData(objData);
    console.log(filterData);
    $.post(urlExport, filterData)
        .done(function (data) {
            console.log(data.locationUrl);
            window.location.href = data.locationUrl;
        });
};

When Export button is clicked exportData function is called:

 var exportToLink = '@Url.Action("ExportTo")';
            console.log('Export to link  in index: '+exportToLink);
            SearchController.exportData(exportToLink);

As I mentioned that this code works perfectly on the local machine. something weird is happening on azure webapp that ExportTo action breakpoint is never gets hit.

I am not sure what else I could change to get the ExportTo action hit?

Answer 1

Based on the Response Header of Azure Web App, we find that the value of Content-Length is 0. It means that no data has been sent from web app server side.

In ASP.NET MVC, we can response file using following ways.

The first way, send the file which hosted on server. For this way, please check whether the excel file has been uploaded to Azure Web App. You could use Kudu or FTP to the folder to check whether the file is exist.

string fileLocation = Server.MapPath("~/Content/myfile.xlsx");
string contentType = System.Net.Mime.MediaTypeNames.Application.Octet;
string fileName = "file.xlsx";
return File(fileLocation, contentType, fileName);

The second way, we can read the file from any location(database, server or azure storage) and send the file content to client side. For this way, please check whether the file has been read successfully. You can remote debug your azure web app to check whether the file content hasn't been read in the right way.

byte[] fileContent = GetFileContent();
string contentType = System.Net.Mime.MediaTypeNames.Application.Octet;
string fileName = "file.xlsx";
return File(fileContent, contentType, fileName);

5/27/2017 Update

Somehow the ExportTo action never gets called. It directly calls the Download action. As a result the TempData null checking is always null.

How many instances does your Web App assigned? If your Web App have multi instances, the ExportTo request is handled by one instance and the Download request is handled by another instance. Since the TempData is store in memory of dedicated instance, it can't be got from another instance. According to the remote debug document. I find out the reason why the ExportTo action never gets called.

If you do have multiple web server instances, when you attach to the debugger you'll get a random instance, and you have no way to ensure that subsequent browser requests will go to that instance.

To solve this issue, I suggest you response the data directly from the ExportTo action or save the temp data in Azure blob storage which can't be accessed from multi instances.