I was just checking out the ajax minfy tool http://ajaxmin.codeplex.com and used this to create a minified js file.It shows in the result the minified and then gzipped file content but I just wanted to make sure that the file is indeed gzipped ..How can I test that and also what happens if we have gzipping enabled in IIS but the file is already gzipped does IIS just renders the file without zipping it again or something else.
Use your favorite debugging tool for the webbrowser (like Firebug) and inspect the HTTP request. If the file was indeed successfully transmitted as a gzipped file, you will see a Content-Encoding: gzip header. It may also say deflate, which is more or less the same thing.
Related
I'm playing around with fetching manually gzipped files from a static file server.
My problem is once I'm not including the Content-Encoding: gzip header in my response, the browser does not recognize content as being gzipped.
Question:
The header is there for a reason, but I'm still wondering whether there are any ways to have the browser (not Javascript) handle a gzipped resource?
Thanks for some pointers! Haven't found any...
Why IE 10 & 11 can't load GZiped content (js and css)?
When I load a page from a server that supports gzip compression, IE loads the first HTML page but fails to load additional js and css files. Showing an error in the console that says something like "invalid character" linking to the GZiped file in question.
It's wierd because IE sends the header Accept-Encoding: gzip correctly, so there is no reason to believe that it doesn't support compressed content.
I've also noticed that no other pages are serving gziped content in IE, as there is no header Content-Encoding: gzip in their responses.
We are serving our static content from AWS S3 and through CloudFront, and as S3 nor CloudFront support file compression on-the-fly, we have our files duplicated. One GZiped and one not.
Any clue of what's happening?
It turns out that the problem was that IE somehow relies on the file name extension to know what kind of file it is loading, instead of using the http response Content-Type header. Our Gziped files were named like their original files, but ending with the extension .gz (e.g. file.js and file.js.gz for its Gziped version). I've renamed all those files, ending them with .gz.js or .gz.css, and it works properly now.
I want to use PIE in my project with IE7.
However something I didn't understand is can i you use .htc files only on web server?
Can i use it in local pages loaded via browser without webserver?
I seen at PIE's documentation and they said this text below:
Serving the correct Content-Type
IE requires that HTC behaviors are served up with a content-type
header of "text/x-component", otherwise it will simply ignore the
behavior. Many web servers are preconfigured to serve the correct
content-type, but others are not.
If you have problems with the PIE behavior not being applied, check
your server configuration and if possible update it to use the correct
content-type. For Apache, you can do this in a .htaccess file:
AddType text/x-component .htc
So if i need load via "text/x-component" Can i do that via AJAX?
It doesn't have anything to do with AJAX :)
It's just a response header of the file. E.G. A HTML page is usually text/html "content-type". A javascript file is application/javascript. This is called the mime type or content type, and helps the browser know what type of file its receiving.
You need to either add a .htaccess file into your web project in the main folder, that has:
AddType text/x-component htc
or add that exact same line into your apache/virtual host configuration.
Can I use JavaScript to detect if the user's browser supports gzipped content (client side, not node.js or similar)?
I am trying to support the following edge case:
There are a lot of possible files that can load on a particular web app and it would be better to load them on demand as necessary as the application runs rather than load them all initially. I want to serve these files off of S3 with a far-future cache expiration date. Since S3 does not support gzipping files to clients that support it, I want to host two versions of each file -- one normal, and one gzipped with content-type set to application/gzip. The browser of course needs to know which files to request. If JavaScript is able to detect if the browser supports gzipped content, then the browser will be able to request the correct files.
Is this possible?
Javascript can't, but you can use Javascript to detect wether or not the browser supports gzipped content.
I commented above and would just like to reiterrate, you should use CloudFront anyway, which does gzip content. If you are using S3, then there is zero reason why you would not want to use CloudFront, however, for the purposes of answering your question...
This blog post perfectly addresses how you would detect if the browser supports Gzip.
http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html
Here is a quick summary:
1) Create a small gzipped file, gzipcheck.js.jgz, and make it available in CloudFront. This file should contain one line of code:
gzipEnabled = true;
2) Use the following code to attempt to load and run this file. You'll probably want to put it in the HTML HEAD section before any other Javascript code.
<script type="text/javascript" src="gzipcheck.js.jgz">
</script>
If the file loads, it sets a flag, gzipEnabled, that indicates whether or not the browser supports gzip.
Well cloudfront does not gzip content automatically. Till the time Amazon decides to do automatic gzip compression in S3 and Cloudfront one has to use the below workaround.
In addition to the normal version, create a gzipped version of the file and upload on S3. If the file name is style.css the gzipped version should be named style.css.gz.
Add a header to the file with key=Content-Encoding & value=gzip to the file. This is needed so that browsers understand that the content is encoded using gzip. The header can be added using S3 api or the popular S3 file manager tools like Cloudberry, Bucket Explorer, etc
Also add the correct Content-Type header for the file. e.g for style.css it should be Content-Type: text/css.
In the webpage include the file normally
Use the above mentioned javascript to detect if the browser supports gzip encoding. If found true replace the file name e.g style.css with style.css.gz
We have an internal web application that acts as a repository to which users can upload files. These files can be any format, including HTML pages.
We have tested than in IE8, if you download an HTML file that contains some script that tries to access your cookies and, after downloading, you choose the "Open" option, the script executes and gets your cookie information with no problems at all.
Actually, that script could use XmlHttpRequest object to call the server and do some malicious operations within the session of the user who downloaded the file.
Is there any way to avoid this? We have tested that both Chrome and Firefox do not let this happen. How could this behaviour be avoided in any browser, including IE8?
Don't allow the upload of arbritary content. It's exclusively a terrible idea.
One potential "solution" could be to only host the untrusted uploads on a domain that doesn't have any cookies and that the user doesn't associate any trust with in any way. This would be a "solution", but certainly not the ideal one.
Some more practical options could be an authorisation-based process, where each file goes through an automated review and then a manual confirmation of the automated cleaning/analysis phase.
All in all though, it's a very bad idea to allow the general public to do this.
That's a really bad idea from a security point of view. Still, if you wish to do this, include HTTP response header Content-disposition: attachment It will force browser to download file instead of opening it. In Apache, it's done by adding Header set Content-disposition "attachment" to .htaccess file.
Note that it's a bad idea just to add Content-type: text/plain as mentioned in one of the answers, because it won't work for Internet Explorer. When IE receives file with text/plain content-type header, it turns on its MIME sniffer which tries to define file's real content-type (because some servers send all the files with text/plain). In case it meets HTML code inside a file, it will force the browser to serve file as text/html and render it.
If you really need to have the users upload HTML files, you should make sure the HTML files in this directory are served with the mime type text/plain rather than text/html or similar.
This will prevent the opened files from executing scripts in the browser. If you're using apache, see the AddType directive.