I've just spent quite a while debugging a problem with content disposition I was having with Internet Explorer 7, the code works fine in Firefox but causes this error message to occur in IE7.
"Internet Explorer cannot download xxx from xxx."
"Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later."
This was my original snippet of C# code:
Response.Buffer = true;
Response.ContentType = docToDisplay.Type.ContentType.ToString();
Response.AddHeader("Content-Disposition", "attachment;filename=" + Server.UrlEncode(docToDisplay.FileName));
I eventually figured out that the following line on code was causing the issue.
I then did a quick search for "Response.Cache.SetCacheability(HttpCacheability.NoCache);" and discovered another developer who have had the same Content-Disposition issue. Unfortunately for me that page didn't get returned when I was searching for the Internet Explorer error message.
This was the response to the post by Microsoft Online Support:
"Yes, the exporting code you provided is standard one and after some further
testing, I think the problem is just caused by the httpheader set by
I just captured the http messages when setting and not setting the above
"NOCache" option and found that when the http response returned the
header. So we can also reproduce the problem when using the following code:
Response.CacheControl = "no-cache";
IMO, this should be the clientside browser's behavior against "no-cache"
response with stream content other than the original text/html content. So
would you try avoid setting the CacheAbility or the "Cache-Control" header
to "no-cache" when you'd like to output custom binary file stream?
Microsoft Online Support"
After removing the Response.Cache.SetCacheability line the file downloads correctly in Internet Explorer.
Ever wanted to be a real web geek?
Well, you can get one step closer by following these steps and browse a website using a Telnet session via the Windows(R) DOS terminal.
Believe it or not you can actually use this method to diagnose HTTP issues, and it also provides an insite into how the HyperText Tranfer Protocol (HTTP) works.
HTTP Request using Telnet
- Open a DOS prompt by clicking Start > Run and typing CMD and hitting Enter.
- Clear your screen of commands by typing CLS and pressing Enter.
- Start a Telnet session by typing telnet and pressing Enter.
- Configure the Telnet session to echo typed characters to the screen by typing set localecho.
- Instruct Telnet how you want to handle the Enter key by typing set crlf.
- Open up a connection to the site you want over HTTP port 80, by typing o nikmakris.com 80.
- Press Enter several times until the cursor lands on an empty line and then request a page from the site.
- Type the following carefully without making errors:
GET / HTTP/1.1
- Then press Enter twice and you should receive the HTML response for the page you just requested from the web server, delivered to you by HTTP!
Here's what you should have typed, and the response from the DOS terminal and Telnet session. I've ommited the verbose HTML response from the web server.
Welcome to Microsoft Telnet Client
Escape Character is 'CTRL+]'
Microsoft Telnet> set localecho
Local echo on
Microsoft Telnet> set crlf
New line mode - Causes return key to send CR & LF
Microsoft Telnet> o nikmakris.com 80
Connecting To nikmakris.com...
GET / HTTP/1.1
Since a site redesign we've been using a custom 404 ASP page rather than our old HTML 404 page, this gives us the opportunity to add dynamic content to the 404.asp page.
However after setting up Microsoft IIS to serve our custom 404.asp page we discovered to our dismay, using a HTTP header viewer, that the 404 page was returning a code '200 OK' rather than a '404 Not Found'.
After some searching the ASP Response.Status object was found. Now with just one line of code at the top of our ASP 404 page we can set the status to 404 Not Found!
Here's the code.
Response.Status = "404 Not Found"
I've added a link to a handy HTTP viewer below.
The amount of data that you can send to the server using WML forms and Nokia WAP enabled phones such as Nokia 3330 and Nokia 7110 is limited. The URL and querystring lengths are also affected since they affect the size of the HTTP header. To fix this problem you have to change the CONNECTION TYPE property to CONTINOUS in the settings menu of the mobile.