I read about everything that i could find at the web for gzip compression of iis
<?xml version="1.0" encoding="UTF-8"?>
I am aware that the first time gzip won't work in order to create the compressed files... this is the awkward part... i use gtmetrix to see what i can do in order to load faster my webpage... Although the code is correct sometimes for no reason gzip isn't working, according to gmetrix report.. i also use fiddler that also points out the same more or less... does anyone have any idea what might going wrong? Thank You! the server is running iis7.6
dynamiccontent in iis roles was missing, once I added that it solved the problem.
Related
This seems to be a common issue but I have tried all the suggestions and none work.
The issue is when I turn on Friendly URLs in ModX Revo all my links get broken (404s). The URLS do appear correct with the alias after them.
Heres what I've tried:
Changing ht.access to .htaccess
Ensuring the correct path is present in MODX_BASE_PATH in the
confic.inc.php file
Ensuring all FURL settings in System Settings are ok and correct
Clearing browser and ModX caches
If anyone can suggest something I've missed that would be great! Thanks
Need some mroe info:
Are you developing locally (WAMP, MAMP..)? If you are make sure that you have mod_rewire enabled in your apache settings. If not make sure it's enabled with your host.
Are you typing the urls in the browser manually (without wayfinder)? (www.yoursite.com/somepage)
OK I set FURL Lowercase Alias's to 'No' in the ModX System Settings and it now works... I do not know why but there you have it...
Perhaps this is because I specified the Resources Alias' before I turned FURLs on and thus they did not actually convert them to lower case
I realize this is an old question but I just install REVO tonight and had issues with FURLs returning 404 errors after I enabled all the settings. What I DIDN'T do was rename the htaccess. Once I renamed that to .htaccess everything is fine. Stupid mistake made with too little sleep but I thought I should post it in hopes I can save someone some wasted time.
My company's Drupal installation leaves me unable to configure permissions from the admin panel. The key problem arises from the "Administer > By Module" page, where clicking on any of the "configure permissions" links results in a Page Not Found / HTTP 500 Error. A number of the settings pages are broken also, meaning that I cannot change the search_config module's settings, either.
I've checked Drupal's dblog messages, and there's no mention of the HTTP 500 errors there. I also wandered into the host's root (I'm on a shared hosting service) and checked out apache's error logs. No dice. Many errors from the other sites on the server, but only 2 old notifications of RSA certificate issues on my domain.
I've been working at this for about a week now, and I'm deeply perplexed as to what can cause this. I've tried turning off clean URLs, and manually entering what I believe to be the URLs for the settings pages, with the same result. This is developing into quite an issue for me, with permissions configuration offline, and also the search_config settings unavailable. Search_config is a big deal also, as I need to exclude some development nodes from the search index, as they are crashing cron's search indexing, preventing it from being up-to-date. Any light that the brilliant minds here can cast on this would be greatly appreciated. Thanks in advance!
Edit: I'd also like to add that I'd looked into PHP settings, and that the php timeout is set at 120, with php memory set at 96M. (Just to be complete! ;) )
Currently running: Drupal 6.22, MySQL 5.1.61, PHP 5.2.17, on a shared Apache 2.2.22 server.
Alrighty. Turns out, in spite of increasing the allocated memory from 64M to 96M, a further increase from 96M to 128M for PHP execution was what did the trick. The menus are all online and functioning correctly. I guess the sheer number of installed modules represents a lot of overhead for the server. Thanks to everybody for looking!
i have a problem where my ASP.NET web application files (.js, .css, .aspx) doesn't get compress when i access it from https. However the files get compressed when i accessed it from http. Any idea what causing this problem?. It over a week and i cannot find any solution from the net. I have ask my network administrator to check proxy settings but they said all ok. My last resort to reinstall IIS but i need to know if you guys have any better solution.
I've setup a website for IIS compression, but it doesn't appear to be working for HTTPS, just HTTP. Is there something that needs to be configured to get this to work, or does this not work in IIS? What options are there?
UPDATE: According to this the compression is occurring before the encryption. If compression is occurring for SSL requests, where do I see it?
UPDATE2: I went back to the metabase.xml file and discovered that the changes I made were gone. Here's what I had:
HcDynamicCompressionLevel="9"
HcFileExtensions="htm
html
js
css
txt"
HcOnDemandCompLevel="10"
HcPriority="1"
HcScriptFileExtensions="asp
dll
aspx
exe"
I'm wondering if the in-memory metabase overwrote the changes I made before I was able to run IISRESET /RESTART??
Thanks!
Chris
I'm not exactly sure how IIS works but I believe that compression gets applied at the end. If that is the case, then it won't work well with encrypted data, which has random-like characteristics. However, it may still be possible to compress your data manually in your application before handing it off to IIS.
The compression should work fine with both normal and ssl traffic, setting it up in IIS can be somewhat tricky, it's often not enough to just toggle the checkbox since it will only compress certain filetypes per default.
IIS Compression
Is your SSL site is pointing to the same application in IIS ? Are you using anything like an SSL accelerator hardware with your server ?
First try the form to the right on the port80 site to see if IIS is compressing: http://www.port80software.com/
For some magical reason ii6 started to cache pages on the server. Even if I remove the page, it is still displayed. I tried to follow couple suggestions but no luck.
That's what I did so far:
Deleted \WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
Unchecked 'cache ISAPI extensions' in the IIS configuration.
Added 'Cache-Control no-cache' to HTTP headers in properties.
Tried to create the page that clear the cache http://www.dotnet247.com/247reference/msgs/13/67641.aspx
Update: also tried to disable asp cache
IIS ASP Caching
But the files in v2.0.50727\Temporary ASP.NET Files are still created
If anybody has other suggestions, please share.
Thanks.
Please give the delete permission for IIS user on below folder. these files will be deleted automatically by IIS
For 64 bit OS folder path:
\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
My classic ASP pages WOULD NOT refresh from any browser. Finally, stopping and starting the IIS service (IIS6) fixed the problem.
You, too, can go bonkers, just like me. Simply have IIS start giving out stale pages! A bargain at half the price!
Did you try restarting the IIS server to see if that stops it from displaying? If it doesn't, then it might not be a caching issue.
I believe restarting the server is supposed to clear the cache.
Maybe the problem isn't the IIS, but a web proxy between your browser and your web server caching the page?
Or a wrong DNS settings pointing to another server which holds a copy of that web/page? You could also look on the same IIS if there is another web configured and host headers got mixed up, making you test on the wrong web.
I might just say the obvious here but have you tried recycling the application pool?
Thanks for replies guys.
I figured out that it wasn't the caching issue. I didn't cleared out Bin folder and the compiled version of the page with extension .compiled was seating there all the time. I don't what changed this time, but I followed the same process like 100 times before and copied files on top without clearing Bin.
I should be more accurate with such things.