I have a web application running on JBoss and I am using IIS 7 for load balancing JBoss instances. Static files (ex: CSS, JS) are served from IIS. I am using mod_jk ISAPI filter to bridge IIS and JBoss.
I have enabled static compression in IIS. However, the CSS files served from IIS were not getting gzip compressed (I have checked this by examining the response header and it doesnt have content-encoding: gzip header).
Post this, I enabled dynamic compression in IIS and then the CSS files were compressed with gzip. I checked my uriworkermap.properties file and it is not routing CSS file request to JBoss. I am puzzled as to why IIS wouldnt compress CSS files with static compression enabled and only compresses when dynamic compression is enabled.
Thanks,
Kishor
This is probably a result of IIS deciding not to compress the content as it's not considered "frequently hit". If you request the file twice within 10 seconds (make sure you're not hitting a cache, ctrl-F5), does it then compress it?
If so, setting the frequentHitThreshold attribute to 1 on the system.webServer/serverRuntime node in the applicationHost.config file should do the trick, as documented at http://www.iis.net/ConfigReference/system.webServer/serverRuntime.
You can do this by executing the following command as an administrator:
%windir%\system32\inetsrv\appcmd set config /section:serverRuntime /frequentHitThreshold:1 /commit:apphost
A word of warning - the "frequent hit" concept does not seem specific to compression. I have no idea whether there are other consequences as a result of setting this!
Related
In apache, the rewrite rule can be written in the configuration file or in .htaccess file. How about in nginx? Can I use url rewriting without access to the configuration file?
Unfortunately, you can't. This is one of the reasons shared hostings typically use apache or litespeed, not nginx or lighttpd.
A (very ugly) workaround would be to handle all requests with a script which would contain the rewrite rules and would serve the file/script according to the request URI (and which could be modified by a user without having root privileges). However you'd have a bad performance serving static files and you'd need to handle all the request headers by this script, which is not very practical.
We use HttpContext.RewritePath() to rewrite the path to static files. We do this to be able to virtualize the location of the static files on the server.
When we do so, IIS seems to behave strangely by sometimes not compressing the content of the file, but by still putting gzip encoding in the http response header. When this happens, browsers fail to properly parse the static file since they try to uncompress cleartext data.
We have been looking around and found a few threads talking about this, but we could not find a satisfying answer as to how to avoid this problem, or why should rewriting paths of static files not be allowed.
Shouldn't it be possible to rewrite the path of a static file?
Here a few pages I found about the issue:
GZip compression in IIS7 not working, but content-encoding header is set to gzip
HttpContext.RewritePath breakes buildin IIS gzip
I want to use GZIP files to reduce the page load time.
I have Converted All my JS files in GZIP files.
Now I want to know How Do I set IIS (I am using IIS 7) that this can be work.
Second thing How do i call GZIP file in My Asp.net Pages as well?
Thanks in Advance
I have Converted All my JS files in GZIP files.
Not necessary. Just enable GZIP compression in IIS settings. This article gives details on how to do so. This SO discussion talks about how to validate that the settings were successfully applied.
Second thing How do i call GZIP file in My Asp.net Pages as well
Compression can be enabled for static and/or dynamic files. ASPX pages are considered a dynamic type; enabling dynamic content compression will cause them to be GZIP'd before they are served to a compatible user agent.
To validate, you can use a tool like http://gtmetrix.com/ which will warn about uncompressed resources.
I'm setting up an ASP Classic website on Win7 x64, I have done the usual trick (Add site as Application to enable global.asa, use Classic pipeline App Pool, Enable 32-bit Applications: True, Load User Profile: False, Enable Parent Paths: True, give Everyone full access to site files, use odbc 32), and the site is up and running for *.asp files. However, I have some files named as *.inc under Includes directory, and IIS doesn't seem to be able to process them.
When I try to access http://localhost//includes/myfile.inc, I got:
HTTP Error 404.3 - Not Found
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
I tried to add a script map in Handler Mapping, similar to the one for *.asp: Request Path = *.inc, Executable = %windir%\system32\inetsrv\asp.dll, Invoke handler only if request is mapped to File, and in the ordered list this new mapping is on top. Now I got this error when request .inc:
HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.
Any ideas?
Why are you trying to load .inc files in the browser? This is not normal behavior. Those files are meant to be included in other files, such as the ASPs.
Blocking those files from being requested is protecting you from revealing your source code, which is what would happen if IIS did serve those files; it would just output their contents verbatum.
Problem:
html file on local server (inside our organization) with link to an exe on the same server.
clicking the link runs the exe on the client. Instead I want it to offer downloading it.
Tried so far:
Changed permissions on the exe's virtual directory to be read and script.
Added Content-disposition header on the exe's directory.
I can't change settings in the browser. It's intended for a lot of people to consume.
You need to set content-disposition in the HTTP header.
This Microsoft Knowledge Base entry has more detail on how to do this.
Runs them where: on the server, or on the client? If on the server: set the handler mappings of the file so that CGI-exe is disabled. If on the client: then this is a web browser issue - it shouldn't be running EXEs directly! What browser is it?
As Dave Webb mentions, you could use the Content-Disposition HTTP header: these can be added using HTTP Response Headers in IIS7 for that directory/file.
Whether a file is downloaded or opened automatically is a browser, not a server, side setting.
The other way of doing it would be to change the MIME type for the file to something like application/octet-stream or similar to try and force your browser to download it.