谷歌Chrome浏览器中Return File()下载功能失效问题排查

Hey there, let's dig into this "network error" you're hitting in Chrome when trying to serve zip files without exposing the original path. I've dealt with similar download quirks before, so here's what's likely going wrong and how to fix it:

First, Let's Diagnose the Issue #

Looking at your code, the biggest red flag is the filename format—you're using slashes (/) in the timestamp part (dd/MM/yyyy). Slashes are invalid characters for filenames across most operating systems, and Chrome can choke on this when parsing the download header, which is probably triggering that network error.

Also, while using Octet as the MIME type isn't strictly wrong, sticking to the proper zip MIME type and adding explicit response headers can eliminate ambiguity for the browser.

Fix 1: Fix the Filename First #

Replace those slashes with a safe character like hyphens. This alone might resolve the network error:

string fileName = "BLEXZ_" + DateTime.Now.ToString("dd-MM-yyyy") + ".zip";

Fix 2: Use Proper Headers & MIME Type #

If the filename fix isn't enough, try explicitly setting response headers to guide the browser on how to handle the download. Here's a revised version of your code:

string DownloadableZipFileName = Product.DownloadZipFileName;
string filePath = Server.MapPath("~/App_Data/Products/Zip/" + DownloadableZipFileName);
byte[] fileBytes = System.IO.File.ReadAllBytes(filePath);
string fileName = "BLEXZ_" + DateTime.Now.ToString("dd-MM-yyyy") + ".zip";

// Clear existing response headers to avoid conflicts
Response.Clear();
// Use the correct MIME type for zip files
Response.ContentType = "application/zip";
// Explicitly tell the browser to treat this as a download
Response.AddHeader("Content-Disposition", $"attachment; filename=\"{fileName}\"");
// Let the browser know the file size upfront
Response.AddHeader("Content-Length", fileBytes.Length.ToString());
// Write the file bytes directly to the response
Response.BinaryWrite(fileBytes);
Response.Flush();
Response.End();

// Return empty result since we're handling the response manually
return new EmptyResult();

Fix 3: Stream Large Files (Optional) #

If your zip files are large, loading the entire byte array into memory can cause timeouts or performance issues. Use streaming instead:

string DownloadableZipFileName = Product.DownloadZipFileName;
string filePath = Server.MapPath("~/App_Data/Products/Zip/" + DownloadableZipFileName);
string fileName = "BLEXZ_" + DateTime.Now.ToString("dd-MM-yyyy") + ".zip";

Response.Clear();
Response.ContentType = "application/zip";
Response.AddHeader("Content-Disposition", $"attachment; filename=\"{fileName}\"");
// Stream the file directly from disk instead of loading into memory
Response.TransmitFile(filePath);
Response.Flush();
Response.End();

return new EmptyResult();

Why This Works #

• Removing invalid filename characters eliminates browser parsing errors that cause the "network error" message.
• Using application/zip instead of Octet gives the browser clear context about the file type.
• Explicit headers like Content-Length and Content-Disposition ensure the browser knows exactly how to process the download without confusion.

内容的提问来源于stack exchange，提问作者Kevin himch