We Keep Coding

File .htc files - Do I need web server?

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.

Is there a way to add X-Frame-Options header to a JavaScript file served through Tomcat?

Can I add X-Frame-Options header to a JavaScript file served through Tomcat? I am adding the header to all jsps programmatically.

A hack (but it'll solve your problem cleanly) is to serve the .js file as a JSP. Literally rename yourfile.js to yourfile.jsp, then change the script-src that loads it into your page. Any modern browser (I've checked, and used this solution in production environments) will load a .jsp file via script-src. I did this for the same reason you are: being able to set response headers on .js files.

using Ajax Minfy To minify and compress files

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.

Can JavaScript detect if the user's browser supports gzip?

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

How can XSS be avoided in HTML downloads?

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.