HTTP Response Behaviour - asp.net

Question

I have two very similar pieces of ASP.NET code that send a file in an HTTP Reponse to the client. They should cause the browser to prompt to save the file. The first one works, the second one doesn't. The HTTP responses as seen in Fiddler are below.
Working:
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 228108
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
content-disposition: attachment; filename=Report.xlsx
Date: Wed, 05 Jan 2011 12:17:48 GMT
<binary data>
Not working:
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Wed, 05 Jan 2011 12:19:21 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 228080
content-disposition: attachment; filename=report 2.xlsx
Cache-Control: private
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Connection: Close
<binary data>
When the first one is seen in Fiddler the browser correctly prompts to save the file. When the second one is seen in Fiddler, nothing observable happens in the browser. Same behaviour in both chrome and firefox.
Any idea why this is happening?
EDIT: ASP.NET code that produces the second response
Response.Buffer = false;
Response.ContentType = #"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";
Response.AppendHeader("content-length", genstream.Length.ToString());
Response.AppendHeader("Content-Disposition", string.Format("attachment; filename={0}.xlsx", filename));
byte[] buffer = new byte[1024];
genstream.Position = 0;
int n;
while ((n = genstream.Read(buffer, 0, 1024) ) > 0)
{
Response.OutputStream.Write(buffer, 0, n);
}

Answer 1

The space in the filename parameter value might cause this. Try the quoted-string syntax instead:
Content-Disposition: attachment; filename="report\ 2.xlsx"
See also RFC 2183.

Answer 2

I'm actually a little surprised the first one is working - I thought browsers were pretty picky about case in HTTP headers.
Try changing the "content-disposition" header to "Content-Disposition".

Answer 3

Problem is here:
Connection: Close
A lot of browsers - especially for downloads - use 100-and-continue to read the headers and check the length of the content. The second will not allow the browser to do that.
(UPDATE)
This is generated because of this line:
Response.Buffer = false;
Remove it and it should work as a charm!

Answer 4

Apparently it wasn't a problem with the response but a problem with the request. Both the HTTP responses in the OP are valid, but the link on the page that produced the second one was inside an asp ajax panel (UpdatePanel). I've been staring at this problem for too long and know too little about HTTP protocol to look into the exact cause of it but the differences in the request headers were these fields:
Working (outside ajax panel):
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Not working (inside ajax panel):
X-Requested-With: XMLHttpRequest
X-MicrosoftAjax: Delta=true
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cache-Control: no-cache
Accept: */*
Problem is now gone after removing the link from the ajax panel. "Connection: Close" is still in the (now working) header so that was obviously nothing to do with the problem.
Thanks for the help!