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
Related
I've got a Next.js site where I'm serving some self-hosted fonts using #font-face and locally the fonts come through fine with no errors and the correct content-type, like so:
But once I get it up on a production server, the fonts are being served, but getting 500 errors and coming through with the content-type text/html.
Not sure what is going on here. I've served fonts through the public folder before on other sites without a problem. This is on Digital Ocean with a custom express server handling a few extra things. I've tried different font file types, moving the font directory, etc.
What's even stranger is that I only get the 500 errors on Chrome. Both Safari and Firefox will serve the fonts with status 200, but their content-type is still txt.
Here is the staging server.
It turned out to be a CORS issue. I had to update my CORS policy through Express.js to allow the remote server. This resolved the issue for me.
I have an issue on a Wordpress website in which the Google Maps doesn't load on Firefox and Safari specifically. The map shows blank and a message Loading map...that never ends on those 2 browsers.
This curious message in yellow is displayed on the browser on Google Chrome:
jquery.min.js?ver=1.11.1:4 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://github.com/googlemaps/js-map-label/blob/gh-pages/src/maplabel.js?_=XXXXXXXXXX with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.
and in Firefox it displays the following message also as a yellow alert:
Loading failed for the <script> with source “https://github.com/googlemaps/js-map-label/blob/gh-pages/src/maplabel.js?_=XXXXXXXXX”.
Any clue on what it only works in Chrome and not in Firefox and Safari? Any clue how to solve it?
Thank you
As from the error, your CSP (Content Security Policy) does not allow you to load scripts from github.com domain.
You can :
Edit your content-security-policy headers to allow https://github.com loading. You can do it from your Apache/Nginx settings, or from PHP (if you use it) but I prefer handling those headers from web-server config.
CSP can also be managed using header meta tag
As you're directly serving from Github, you may need to change the default-src as content-type is text/html. I don't know if the script-src will handle it.
Download and upload the script to your server. Like this, it'll be loaded from the same domain, and should not throw CSP error.
Also:
Using files directly from GitHub is not the best idea. As you can see here and from your console error with MIME type text/html, Github serve your JS file as text/html instead of application/javascript.
It would be better to use a proper CDN (if a CDN serving your file exist), or store the file on your server.
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.
I ve to servers with my project. I would like to understand why there is a difference in the behaviour on these 2. On the first one whne i click on:
OPEN
the new tab is opened with pdf being rendered and on the other server(the same browser - chrome) new tab is opened but instead of starting rendering pdf download window appears.
Thanks for any sugestions and explanation
the server is IIS 6.0
The one that is downloading the content does not have MIME types are not configured properly.
It is treating the files are unrecognized static files.
Since the Content-Disposition header is not set it properly, the browser doesn't know it can render those types.
Steps to configure MIME types
The two servers probably send the PDF file with different MIME types in the header, because they are configured differently. If you want PDFs to be opened in the browser, the correct MIME type is application/pdf, as defined in RFC 3778.
Here is a step-by-step tutorial on how to configure MIME types in IIS 6.0:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/cd72c0dc-c5b8-42e4-96c2-b3c656f99ead.mspx?mfr=true
Seems like one of the browsers has a plugin available, or configured by mefor opening the document itself, while the other one doesn't (this might also mean that the MIME type of the file isn't properly configured so the browser doesn't know what to use to open the file).
If you want to force all browsers to show the download dialog (attachment) or trying to open it (inline), you can do so with the Content-Disposition header field. For instance:
Content-Disposition: attachment; filename="fileTitle.pdf"
or
Content-Disposition: inline;
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'