Im working on a web application to be hosted internally and accessed by ~150 people. Because of the nature of the business, lof of images move between browser and the server. I want to ensure that other content like text is compressed. I think I have made the necessary setting on the IIS 7.5 server.
Now when I request a page and check the response headers with the fiddler2 tool, it says "Transport
Content-Encoding:gzip.
And I also see a message "Response is encoded and may need to be decoded before inspection. Click here to transform"
However when I see the response headers using IE developer tools, network tab, there is no mention of gzip encoding.
So my question is : Is my content really compressed as fiddler2 says or is it not compressed like IE tools show.
As always all help/guidance is greatly appreciated.
Related
My web application creates a zip file to download files related to a "Task" instance. This zip file can contain images, .pdf or .txt files, the filename created has the form "{taskName}.taskBundle".
To download the file, the web application use the following headers in the response (from Firefox Network monitor):
Content-Disposition: attachment; filename="task1.taskBundle"
Content-Type: application/zip;charset=UTF-8
The problem:
Using Firefox 84.0 (Ubuntu and Windows versions), the browser is replacing the '.taskBundle' extension by '.zip', so the downloaded filename is "task1.zip" instead of "task1.taskBundle".
I tried to download the same file with Chrome (87.0) and another Firefox versions (83.0, 82.0, 80.0, 74.0) and the file name is correct: "task1.taskBundle".
Maybe should I add another header to the response to prevent Firefox change the file extension?
I can change the Content-Type to 'application/octet-stream' but the checkbox "Do this automatically for files like this from now on." is not displayed in the download dialog.
Additional notes:
My app is written using Grails 3.3.9 but I think it is not a Grails issue because the response headers are sent to the client as described before.
We're fixing this in https://bugzilla.mozilla.org/show_bug.cgi?id=1684183 , but it'll likely not be before Firefox 85 (ie we won't be shipping a security / out-of-cycle dot-release fix just to address this issue).
A simpler workaround for your usecase would be choosing / standardizing on a specific mimetype for these "task bundles", along the lines of application/x-my-fancy-application-task-bundle, if you don't want the UA to treat it as a zip file.
Both Firefox and other browsers can decide to act on the mimetype (e.g. in Firefox's case, we show "Open in Firefox" options if you send application/pdf or SVG mimetypes, even for Content-Disposition: attachment responses, to simplify opening the content immediately). Chrome has specific checks for application/zip when sniffing.
The regressing change here was part of a fix to handling web servers who send foo.jpg files with Content-Type: image/webp, where users complained that the resulting .jpg files were not, in fact, jpegs. So we added extension normalization for a number of different mimetypes. I mistakenly assumed that application/zip files would be, you know, zip files, and could be treated as such.
You might want to report this on Mozilla's Bugzilla site (https://bugzilla.mozilla.org) under Firefox as I can't find a report that describes this exact behavior. It looks like they've broken something in the latest version (whether it was a bug or a feature is hard to say) as I noticed this behavior on a site with a mismatching Content-Type too.
Of course, if it was an intentional change, it wouldn't be the first time the Mozilla has ignored web standards to do things "their way". It still annoys me to no end that I have to use the 5-slash hack to get file protocol links to open correctly when the standards clearly state otherwise (see: https://bugzilla.mozilla.org/show_bug.cgi?id=992123)
I have a mac, I need to test my website on Microsoft Edge in Windows using a virtual box. I want to add some http request headers to the call. However, I only found https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mobile/mcsf/custom-http-headers-for-internet-explorer which is for the phone. I didn't find anything for desktop. Since it is on virtual box, I doubt apps like Charles would work either.
Take a look at fiddler from Telerik.
It's a free web debugging proxy. With it you can intercept and modify pretty much everything that flows in and out of your browser.
Telerik Fiddler
From the menu choose Customize Rules. Adding a request header would require something like this to be added. The sample file is well documented.
oSession.oRequest["someHeaderToSend"] = "someValue";
I am getting IE9 "only display secure content" warning on my page. It calls a large number of frames etc that I did not write so I am looking for way to get IE9 to show me what it considers the insecure (http) page that being asked to be loaded. Is there a way to this? I also have access to IE7 & 8. I don't generally have any other tools on the machines with IE because they are just short term VMs, running MS's testing builds of IE7,8,9.
Open Fiddler, then click Allow in the warning.
Fiddler will show you all of the non-SSL requests.
You can also just look in Firebug's Net tab.
I've enabled gzip compression in IIS using the config settings specified in this answer.
When I request a text file using Firefox, I can see in Firebug that the response is gzipped:
But when I request the same text file using IE9, the dev tools show it is not gzipped:
Why is IIS not sending the txt file compressed? Am I missing some IIS setting? Is my browser misconfigured?
I'd compare both requests using Fiddler since IE dev tools doesn't seem to be showing all response headers
I desperately need help with this one. I have a classic ASP website in IIS 5, where I need to stream pdf to users. I am using ADODB.Stream to generate chunks of binary data and using response.BinaryWrite to stream it to client. Now problem is that there is a known feature in IE which sets the Response CacheControl header to "no-cache" by default for SSL (https) sites. Hence I am getting the standard error:
"Internet Explorer cannot download File.doc from ServerName.
Internet Explorer was not able to open this Internet Site. The requested site is either unavailable or cannot be found. Please try again later."
I have set Response.CacheControl = "private,must-revalidate,max-age=3600" before streaming, but it still give the error.
Note: The same code works perfectly in all other browsers like firefox and netscape.I am using LiveHttpHeaders in firefox to see that Response.CacheControl is automatically set correctly in firefox. Unfortunately i cannot install Fiddler on my machine, but i am guessing problem is due to IIS default header CacheControl = "no-cache" for https
I have unchecked the "Do not save encrypted pages to disk" option in IE.
I need a way around this since the option has to be made available very soon to users over the internet with existing technology :(
Start here: http://blogs.msdn.com/ieinternals/archive/2009/10/02/Internet-Explorer-cannot-download-over-HTTPS-when-no-cache.aspx to see a fuller discussion of this issue. It's quite likely that you're sending one or more headers that forbid caching.
The statement...
there is a known feature in IE which
sets the Response CacheControl header
to "no-cache" by default for SSL
(https) sites
... is incorrect. Did you mean to say "IIS"? Which version? I've never heard of such a feature.
I don't know why you can't use Fiddler on the machine in question?
maybe this could help:
Link
I solved a similar problem checking "enable content expiration" on the http headers tab of the iis management console.
You might be able to get away with dropping support for Internet Explorer 5.5 as it has less than .5% of the market. It so low they stopped tracking it on in jun 08'