Very Strange ASP.NET MVC and IE8 Link/URL Issue

I've got a really strange issue in MVC/IE8 and I was wondering if anyone had seen anything like it. I've got a URL that returns an excel spreadsheet in the form http://application.mycompany/Controller.aspx/Action/ID1/ID2 (I am using the .aspx in the route due to the version of IIS). This opens from a page with the application, fine. I also have e-mails with HTML bodies that get sent around that have links in them and all the links open fine apart from this one - it gives an error saying "Cannot download ID2 from application.mycompany, IE was unable to open the site". I've checked the HTML in the e-mail and the link location on the page that works and they are the same. If I type the exact link text (or copy and paste it from the e-mail) into the IE address bar it again fails, but then if I click on the same text in the addres bar at the end and hit enter a second time it loads and spits out the file. It seems to work ok pasting it straight into FireFox, but I can't check clicking on the link and loading FF as I'm working remotely and don't have Firefox on my citrix desktop, nor can I find anyone who has it as their default browser (but as it works first time, I would imagine it would be ok).

Has anyone seen this before or got any ideas what might be causing it, please? This issue occurs on more than one machine, so it isn't an odd add-in/setting as far as I can see.

Thanks

MH

----------------------------Update----------------------- I've used Fiddler to see what's going on and the response to both requests is identical, apart from the timestamp. Failed response:-

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/vnd.ms-excel; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
content-disposition: attachment;filename=Filename.xls
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 20 Dec 2010 10:31:52 GMT
Content-Length: 2354

<style type"text/css">.text { mso-number-format:\@; } .TableHead { background-color: #BDBDBD; } </style>
....confidential file content removed

Successful response:-

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/vnd.ms-excel; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
content-disposition: attachment;filename=Filename.xls
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 20 Dec 2010 10:32:18 GMT
Content-Length: 2354

<style type"text/css">.text { mso-number-format:\@; } .TableHead { background-color: #BDBDBD; } </style>

and just to reiterate, the only thing I do to generate the second request is to click on the URL text in the address bar that generated the first request and hit enter.

The error I get is ""Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be fo开发者_运维知识库und. Please try again later."

To quote the similar discussion on the Sitepoint forums.

It's the caching, if you select no-cache IE can't find the file to save it, but if you allow caching it works. Annoying as the same file can be downloaded at different times and may well be different if things have changed, so caching is a little dangerous (I'll have to suffix the filename with a timestamp to avoid this, I think). http://support.microsoft.com/kb/316431 so this fixes it Response.Cache.SetCacheability(HttpCacheability.Private); but it still doesn't explain why it sometimes works, esp directly from the web page link

"This behaviour is by design" - translation "we can't get this to work and CBA to get it working" - amazing how firefox, opera and chrome don't have this problem......

This kb article might help shed some light:

http://support.microsoft.com/kb/316431

"Web sites that want to allow this type of operation should remove the no-cache header or headers."

I've seen some wierdness around IE + Outlook + mailto links with large numbers of characters. Above 128 characters, mailto links do not work with IE + Outlook.

I would try to decrease the number of characters in your anchor to see if you can get it to be more reliable.