2017-05-25 11 views
0

ここで何が起こっているのかわかりません。Azure Webアプリケーションでの応答ヘッダーの問題

ウェブアプリケーションをローカルで実行してボタンをクリックしてファイルをダウンロードすると、そのファイルは正常にダウンロードされ、添付のスクリーンショットにある「レスポンス」ヘッダーがローカルに表示されます。

しかし、私は晴れのWebアプリケーションにアプリケーションを公開します。何とかダウンロードボタンが機能しなくなります。レスポンスヘッダーを確認したところ、違いがわかりました。

この問題の原因は何ですか?コードは同じですか? azureポータルのazure web appに設定する必要のある設定はありますか?コード

を追加するために更新

enter image description here

私は@Amorが示唆したように何が起こっているかを把握するためにリモートでデバッグしています。

私のローカルマシンで最初にデバッグするとき、TempDataを準備するExportToアクションがヒットすると、ダウンロードアクションは、最初のアクションがajaxコールで完了すると呼び出されます。

ただし、リモートでデバッグする場合はそうではありません。何とかExportToアクションが呼び出されることはありません。ダウンロードアクションを直接呼び出します。その結果、TempDataのNULLチェックは常にnullです。

なぜですか?なぜ地球上で、それがどうやって可能ですか?どこかにキャッシュされたものはありますか?

リモートでWebアプリケーションの内容を消去して、すべてが更新されているかどうかを確認するために、レビエーションを再公開しました。しかし、まだ成功はありません。ここ

はコードです:ここ

[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(); 
    } 

は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; 
     }); 
}; 

[エクスポート]ボタンがクリックされるとするexportData関数が呼び出されます。

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

私はこのことを述べたようにコードはローカルマシン上で完全に動作します。奇妙なことにazure webappでは、ExportToアクションのブレークポイントは決して打撃を受けません。

Export Toアクションヒットを得るために何が変更できるのかよくわかりません。

答えて

2

Azure Web Appの応答ヘッダーに基づいて、Content-Lengthの値が0であることがわかります。つまり、Webアプリケーションサーバー側からデータが送信されていないことを意味します。

ASP.NET MVCでは、以下の方法でファイルに応答できます。

最初の方法は、サーバーでホストされているファイルを送信することです。このように、ExcelファイルがAzure Web Appにアップロードされているかどうかを確認してください。あなたは、ファイルが存在するかどうかを確認するために、フォルダにKuduまたはFTPを使用することができます。

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

第二の方法は、我々は、任意の場所(データベース、サーバーまたはAzureストレージ)からファイルを読み込み、クライアント側にファイルの内容を送信することができます。このようにして、ファイルが正常に読み込まれたかどうかを確認してください。 remote debug your azure web appを使用して、ファイルの内容が正しい方法で読み取られていないかどうかを確認できます。

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

2017年5月27日更新どういうわけかExportToアクションが呼び出されることは決してありません

。ダウンロードアクションを直接呼び出します。その結果、TempDataのNULLチェックは常にnullです。

Webアプリケーションに割り当てられるインスタンスの数はいくつですか? Webアプリケーションに複数のインスタンスがある場合、ExportTo要求は1つのインスタンスによって処理され、ダウンロード要求は別のインスタンスによって処理されます。 TempDataは専用インスタンスのメモリに格納されるため、別のインスタンスから取得することはできません。リモートデバッグドキュメントによると。私は、ExportToアクションが決して呼び出されない理由を知ります。

複数のWebサーバーインスタンスがある場合は、デバッガにアタッチするとランダムなインスタンスが生成され、後続のブラウザ要求がそのインスタンスに確実に送信されることはありません。

この問題を解決するには、ExportToアクションから直接データに応答するか、複数のインスタンスからアクセスできないAzureブロブストレージに一時データを保存することをお勧めします。

+0

ご回答ありがとうございます。コードを追加するために質問を更新しました。私はAzure Webアプリケーションを遠隔からデバッグしました。私は質問で詳しく説明したように、1つの問題を見ることができます。なぜこれが起こっているのか? – akd

+0

あなたのコメントに基づいて私の答えを更新しました。 – Amor

+0

私は、Webアプリケーション用のazureによって作成されたインスタンスは認識していませんでした。私はあなたがこれで私を救ったと思います。私はWebアプリケーションのARR Affinityを無効にしました。今はすべてが理にかなっています。だから、もしあなたが、tempdataを持っているなど、完全にステートレスではないアプリケーションを持っているなら、デバッグはかなり役に立たないとARRアフィニティーを無効にしてください。しかし誰かがこの素晴らしいアイデアについてのブログを書くべきです。問題に戻ると、フィルタデータを渡すためのajax呼び出しによって呼び出されるため、ExportToアクションからデータに応答することはできません。 – akd

関連する問題