When downloading a file from an IIS6-hosted ASP.NET MVC 3 application, the content-length header is not set for .exe files.
MIME-types appear to be correctly set. (.exe is application/octet-stream). Static content compression is disabled.
As far as I can tell, this problem is specific to .exe files. .zip works fine.
Suggestions?
Update
Here are the headers that are being sent:
Accept-Ranges:bytes
Cache-Control:max-age=86400
Compression-Control:whitespace
Content-Encoding:gzip
Content-Location:http://...../someFile.exe
Content-Type:application/octet-stream
Date:Wed, 28 Aug 2013 15:45:52 GMT
ETag:"5397aeeb6e4ace1:0"
Last-Modified:Mon, 06 May 2013 15:32:30 GMT
Transfer-Encoding:chunked
Vary:Accept-Encoding
Turned out we had an ISAPI filter running that was stripping out some headers, including this one.
Disabling the filter fixed the problem.
Related
I have a web application that offers file downloading functionality. I would like to enable browser cache (Cache-Control header) so that subsequent downloads of a file come from the browser cache, instead of generating a new HTTP Request to the server.
HTTP Request:
http://localhost:9080/webapp/action/content/somefile.exe
HTTP Response:
Cache-Control:max-age=600
Content-Disposition:inline;filename="somefile.exe"
Content-Length:20952624
Content-Type:application/x-msdownload
Date:Thu, 22 Oct 2015 10:46:17 GMT
Last-Modified:Thu, 22 Oct 2015 10:44:49 GMT
X-Powered-By:Servlet/3.1
However, despite the Cache-Control header, the browser (latest releases from Firefox & Chrome) always asks the server for the file. Any idea why?
I have an ASP.NET / MVC web app which when running locally produces this header:
Cache-Control:public, max-age=3
Connection:Close
Content-Encoding:gzip
Content-Length:287122
Content-Type:text/javascript
Date:Thu, 26 Jul 2012 21:21:26 GMT
ETag:K5fBpkMM+t9XPl07ydQ54pR6bg8=
Expires:Thu, 26 Jul 2012 21:21:29 GMT
Server:ASP.NET Development Server/10.0.0.0
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
But when running in AppHarbor behind their proxy the headers I get are these:
Cache-Control:public
Connection:keep-alive
Content-Encoding:gzip
Content-Length:287122
Content-Type:text/javascript
Date:Thu, 26 Jul 2012 21:22:49 GMT
ETag:K5fBpkMM+t9XPl07ydQ54pR6bg8=
Expires:Thu, 26 Jul 2012 21:22:41 GMT
Server:nginx
AppHarbor is stripping the Max-Age portion of my Cache-Control header and stomping over my Date with one I'm not synchronized with.
My goal is serve JavaScript via a CDN with a very short max age so that changes can be rolled out quickly. Changing the url frequently is not an option.
Does anyone know how to fix this?
A college who more closely examined the RFC noticed that it looks like the common one line form of this header used by servers and browsers:
Cache-Control: public, max-age=X
isn't actually valid. Splitting the two parts of the header into two lines like so:
Cache-Control: public
Cache-Control: max-age=X
works! So in my .net code, this:
response.Cache.SetCacheability(HttpCacheability.Public);
response.Cache.SetMaxAge(MaxAge);
becomes this:
response.AddHeader("Cache-Control", "public");
response.AddHeader("Cache-Control", "max-age=" + (int)MaxAge.TotalSeconds);
and now I can get a max-age out of AppHarbor.
I have a website containing a link to an RDP file. When the user clicks the link, the file should be offered as a download. It works with every browser, also in IE9 on localhost. But online, IE9 does not recognize the file type and the file name, and clicking on save causes an error. Did I forget a correct header? Or are there some trusted site settings I have to change since it works on localhost?
I get the following headers when accessing the rdp file:
Date: Mon, 19 Dec 2011 12:58:50 GMT
Content-Disposition: attachment; filename="Demo_WIN.rdp"
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 72
Keep-Alive: timeout=15, max=46
Connection: Keep-Alive
username:s:Tester431
full address:s:176.1.2.3
domain:s:MYRDP
I think you need to set the content type to "application/rdp". Here are the relevant headers I use, which work on every browser I've tried, including IE9:
Content-Type: application/rdp; charset=utf-8
Content-Disposition: attachment; filename=Application.rdp
We have recently moved to a new web server (from IIS6 to IIS7.5) and I'm having some trouble updating our VSTO word addin.
Our app checks for updates manually when logging in and if a newer version has been found updates like this (let me know if there is a better way to do this - I've tried ApplicationDeployment.Update() but had no luck with it either!):
WebBrowser browser = new WebBrowser();
browser.Visible = false;
Uri setupLocation = new Uri("https://updatelocation.com/setup.exe");
browser.Url = setupLocation;
This used to launch the setup and update the app and when the user restarted word they would have the new version installed. Since the server move the update no longer happens. No exceptions are thrown. Browsing to the URL launches the updater as expected. What would I need to change to get this to work?
Note I have the following MIME types setup on the folder in IIS:
.application
application/x-ms-application
.manifest
application/x-ms-manifest
.deploy
application/octet-stream
.msu
application/octet-stream
.msp
application/octet-stream
.exe
application/octet-stream
Edit
OK I've had a look in fiddler and its returning a body size of -1:
If I enter the same URL in IE you can see that the setup.exe is launched without problems.
This is what fiddler displays in the raw view when accessing from word:
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Last-Modified: Tue, 27 Sep 2011 15:07:42 GMT
Accept-Ranges: bytes
ETag: "9bd0c334277dcc1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 14 Nov 2011 07:42:18 GMT
Content-Length: 735608
MZ��������������������#������������������������������������������ �!�L�!This program cannot be run in DOS mode. $�������
*** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***
Have you tried a tool like (for instance) fiddler2 to see what http traffic is actually created?
Does the client make a server call? What does the server actually return?
Then:
Make the calls from within word (which isn't working)
Make the calls by hand (which is working)
Compare both the request and response packages from those calls to spot the differences
I'm getting the following warning for a one of css files in my installation:
Resource interpreted as Image but transferred with MIME type text/css.
How to solve this problem?
I'm running apache2 with ruby on rails 2.8.11.
The server is definitely sending the correct content type:
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:803
Content-Type:text/css
Date:Wed, 15 Jun 2011 04:20:45 GMT
ETag:"66941-921-49f967c2bd200"
Keep-Alive:timeout=15, max=96
Last-Modified:Tue, 29 Mar 2011 03:16:24 GMT
Server:Apache/2.2.12 (Ubuntu)
Vary:Accept-Encoding
But still, browser is claiming that "resource is interpreted as Image".
I had this same problem and solved it by fixing one of my CSS files.
I changed the code:
body { background:url(''); }
For:
body { background-image:none; }
Explanation:
Since url('') points to itself, and it is a .css file, the browser couldn't find the image it was looking for to fill url.