Content-disposition attachment filename gets different results in Firefox and IE

In Firefox, You need to wrap filename with double quotation marks to get the desired name. Otherwise, if there is space, the part after the space will be discarded.
IE converts spaces to _. Therefore, the name must be processed by the HttpUtility. UrlPathEncode method.
If the name is also processed using HttpUtility. UrlPathEncode in Firefox, the space will be replaced with "% 20 ".

1 HttpContext. Current. Response. Buffer = true;
2 HttpContext. Current. Response. ClearContent ();
3 HttpContext. Current. Response. ClearHeaders ();
4 HttpContext. Current. Response. ContentType = "Application/pdf ";
5 string doc1 = System. IO. Path. GetFileNameWithoutExtension (doc) + "_" + intNewID. ToString () + ". pdf ";
6
7 if (HttpContext. Current. Request. Browser. Browser! = "IE ")
8 HttpContext. Current. Response. AddHeader ("Content-Disposition", "attachment; filename = \" "+ doc1 + "\"");
9 else
10 HttpContext. Current. Response. AddHeader ("Content-Disposition", "attachment; filename =" + HttpUtility. UrlPathEncode (doc1 ));
11 byte [] buffer = System. IO. File. ReadAllBytes (doc );
12 HttpContext. Current. Response. AddHeader ("Content-Length", buffer. Length. ToString ());
13 HttpContext. Current. Response. BinaryWrite (buffer );

Firefox does not handle filenames with spaces. when a user clicks on an attachment with spaces, the filename is truncated to the first whitespace. while IE & Safari both handle this, Firefox refuses to accept mime headers with unquoted filename parameters. according to Firefox's bugzilla/knowledgebase, Firefox's behavior is the correct behavior and it's a problem with most webservers or web applications. this problem can be easily corrected by surrounding the filename parameter with double quotes.