This might sound like a strange request, but I need to test something and need the ability to disable compression on a Windows Azure website. The site is running as a website in preview mode and this means I am not able to log into the VM to adjust the IIS settings.
I updated the web.config file accordingly, but this didn't make a difference.
<system.webServer>
<urlCompression doStaticCompression="false" doDynamicCompression="false"/>
</system.webServer>
Compression is still enabled and it seems that it is enabled by default. There are a lot of questions on SO about enabling compression, but I cant seem to find any about disabling compression!
Does anyone have any advice!?
Not every setting in web.config is delegable when deploying your web application to Windows Azure Websites. Some of the settings in web.config are delegable and they reflect in your websites while other settings are respectfully ignored and disabling compression is one of them and that is why you see the above results. Using same exact web.config setting or using Appcmd, you sure can disable compression only if you have enough control on your IIS server. So far if this feature is must important for you, your other options are to use Windows Azure Cloud Service and deploy a Web Role or use Windows Azure Virtual Machines as well.
I am sure that disabling compression feature in Windows Azure Websites is still not delegable and that's why it is not supported in current preview release of Windows Azure Websites. I can say that it sure is a feature in consideration to include in later releases however, about it's availability when or if possible, i do not have any comment.
I know that this question has been posted since a long time ago, at this date I was able to turn off http compression by setting it up in IIS.
the same way as #Deano suggested
<system.webServer>
<urlCompression doStaticCompression="false" doDynamicCompression="false"/>
</system.webServer>
Related
Since about a week when I publish a new version of our Web App and do a Swap from Staging to Production, it actually seems to swap before the warmup initialization is done.
As it is a large application it will takes more then five minutes to warmup the site, making the application unresponsive.
I have official Azure support, but it is taking a long time to respond to this request and I still have no answer that works.
I can't fix any issues on our platform or publish a new version without bringing the whole site down for eight minutes. This is a highly visited website, with paying clients.
Does anyone know:
anything that I could investigate myself?
a workaround or any tips that I can take a look at myself to try to fix or work around this issue?
Extra information
I do use applicationInitialization, and I see that Azure is hitting the pages - it just happens after the swap instead of before.
<system.webServer>
<applicationInitialization>
<add initializationPage="/nl" hostName="mydomain.com" />
<add initializationPage="/warmup-application-for-azure" hostName="mydomain.com" /> (special page just for warming up services)
<add initializationPage="/deeplink1" hostName="mydomain.com" />
<add initializationPage="/deeplink2" hostName="mydomain.com" />
[etc]
</applicationInitialization>
</system.webServer>
Maybe not 100% relative to this question but since I had similar issue with warm up I want to share how I solved it.
I used to have issue with auto-scaling because my nodes were not warmed up due to url rewrite module. So what if you have url rewrites in your app make sure that you are checking for
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
Now this is in official documentation and it has link to common problems
This was an Azure bug, confirmed by the Microsoft Azure team.
Sometimes hitting the site’s root URL is not enough to completely warm up the application. For example it maybe necessary to hit all important routes in an ASP.NET MVC app or to pre-populate the in-memory cache. That is where the Application Initialization Module can help.
When you use the warmup-functionality provided by IIS (and Azure) instead of those old-fashioned methods and if deploying to an App Service, just add a slot setting to make sure it always triggers such as below:
This tutorial explains how you can use the recently enabled Application Initialization Module to completely warm up your application prior to swapping it into production.
So here is the important thing you should consider:
Unless you specify which url address azure needs to request to your website, how can it knows. If you don't do that, it only calls the root of the application
Even if you specify the url and your url needs to authorisation/authentication, how can azure sign in your website automatically and call the url that you specify.
You have got two option to deal with it.
1) Write your own warming up api to call your web application with authorisation/authentication. Then create a scheduler to call the application every hour or half an hour. It also allows you to keep the entire application up & running & warm. You can also set AlwaysOn feature under the Application Settings. You can also trigger this api on your CI/CD pipeline after the staging slot deployed successfully.
2) If you don't want to touch your CI/CD pipeline or whatever reason and don't want to write api, you should sign in to your web application, go through each page and warm it up manually. Then you can swap without any problem.
I'm trying to deploy web pages on IIS. When I try to browse site I got such mistake:
This configuration section cannot be used at this path. This happens
when the section is locked at a parent level. Locking is either by
default (overrideModeDefault="Deny"), or set explicitly by a location
tag with overrideMode="Deny" or the legacy allowOverride="false".
Section in my config file:
<security>
<authentication>
<basicAuthentication enabled="false" />
</authentication>
</security>
May anybody help me to "unlock" parent section (as far as I understand).
You may need to allow feature delegation.
IIS Manager -> Feature Delegation
Select "Authentication - Basic" and change it to Read/Write.
By default it is ReadOnly.
I had the same kind of problem when I tried to deploy ASP.NET pages on IIS. (To be honest don´t know if exactly the same - I am using Windows 10 now, but got same kind of message).
At first it seamed complicated to fix but found out that had a really easy solution.
I Just needed to reinstal IIS at the Control Painel - but with ASP option enabled (I enabled all of the resources for development of applications).
And at the Website (basic) configuration had to select .NET v4.5 Classic.
Error 500.19 and file execution issues and locked on IIS 8
To resolve it I had to execute in cmd:
%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/handlers
%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/modules
I have an MVC app hosted on an Azure Website.
I have custom errors enabled and working (when not publishing):
<customErrors mode="On" defaultRedirect="~/Error/NotFound" xdt:Transform="Replace">
<error redirect="~/Error/NotFound" statusCode="404" />
<error redirect="~/Error/NotFound" statusCode="403" />
</customErrors>
When I publish the website from Visual Studio, if I try to visit the site while the dlls are being updated, I get a nasty IIS error.
I'm surprised that Azure doesn't wait to "tie down" the new version until the publication is complete, to avoid this scenario. Is there a way to achieve this "instantaneous switch" behavior?
And/Or - How can I prevent this error from being displayed?
I can't say this would be unusual. Depending on size of the deployment it may take a while for IIS to restart and reload leading to 503 Service Unavailable or similar errors in the meantime. CustomErrors won't help you here as the ASP.Net pipeline isn't even being reached at this point. What Azure Website level are you running on (Free, Shared or Standard?) If you can up the size of the instance to try and get things moving again more quickly.
I think you deployment is too slow. IIS detects changes in dll files and restart the app-pool automatically without waiting for the other dll files.
Try to set custom values in waitChangeNotification and maxWaitChangeNotification in web.config. Doing so you can ask IIS to wait for some seconds before restarting app-pool. I'm not sure if it works on Azure. On my on-premises IIS I use custom values that allow me to do a long deploy (about 5 seconds).
Documentation: http://msdn.microsoft.com/en-us/library/e1f13641(v=vs.85).aspx
I've got an existing Umbraco install on Azure cloud services (not Azure web sites), and although the web.config tells me that it should be found at ~/App_Data/umbraco.config, it isn't there.
Does anyone know where this would be stored? Is there a chance it is writing to a db table perhaps?
I need to edit some nodes as I suspect that at least one is owned by a user which no longer exists, hence no nodes at that level are visible in the admin system (JS error).
The site was set up with Umbraco Azure Accelerator, if that offers any clues.
Thanks!
It is worth noting that Umbraco hasn't needed the Umbraco Accelerator for Azure in the latest versions due to the use of Azure Web Sites. I am wondering which version of Umbraco you are running? The Accelerator projects are being deprecated and have ceased updates, as you can see here by the lack of recent updates. You can read more about the reasoning behind this, and about how the Accelerator's functionality is now a part of the Azure core itself, over here.
So - assuming that your site is an old one and you cannot just reinstall it as an Azure Web Site, can you firstly please confirm that you have the config enabled through the following setting in /config/umbracoSettings.config?
<XmlCacheEnabled>True</XmlCacheEnabled>
If this is false (as is best during all hosting environments except live) then we know that Umbraco will not use the cache. Can you please also check that the following section doesn't list any other machine IP addresses in umbracoSettings.config? Note that this is only relevant if the enabled attribute is true as in the example below.
<distributedCall enabled="true">
<user>0</user>
<servers>
...
</servers>
</distributedCall>
Next, we need to check that Umbraco is still set to use the location /App_Data/umbraco.config through the web.config file.
<appSettings>
<add key="umbracoContentXML" value="~/App_Data/umbraco.config" />
</appSettings>
We should consider the way that Umbraco works on Azure and whether it could have any effect on your site. The Umbraco Accelerator used to be necessary to synchronise the umbraco.config file between Azure instances. With each instance running a separate Umbraco website, there has to be a way that they can talk to each other. The accelerator mirrors that cache file between instances.
Assuming that your code is a default install, and not having been worked on by someone else before you, then it could be an idea to reduce your site to a single instance. Now see if it generates the cache after restarting the website. Finally, you can upgrade the site to see if it regenerates the cache.
These issues are usually always caused by some kind of configuration issue. I also remember that you can simulate Azure deployment using the Windows Azure SDK which you can use to examine for signs of the cache. Good luck.
I'm not sure about the Umbraco Accelerator or a non Web Site project, but we currently are running Umbraco on an Azure web site and App_Data\umbraco.config comes and goes when it pleases and the website unexplainably works. I would like to find the reason behind this if anyone has an answer??
I am trying to use Enterprise Web Library with Windows Azure. It appears that the web.config file for the EWL project works fine locally, but when I deploy to Azure the application cannot initialize. After logging in and viewing the site locally on Azure, it appears there are several web.config elements EWL requires that are locked on Azure. I've had to edit the following in order to have the application initialize on Azure:
Remove <serverRuntime uploadReadAheadSize="8388608" />.
Remove everything nested inside of the modules element.
The application seems to run fine on Azure after removing these parts.
The Web.config elements you removed are important to ensure that EWL works properly: uploadReadAheadSize fixes a problem with client certificate authentication, and using <clear/> in the <modules> section makes the behavior of EWL applications consistent across different servers by keeping the same set of modules in the pipeline regardless of what IIS features are installed on the machine.
There has to be a way to unlock these config sections in an Azure web role. Assuming they are locked in the web role's applicationHost.config file, maybe you can modify this file using a startup script as described in this answer: https://stackoverflow.com/a/10140024/35349.
I am not very familiar with Enterprise Library. If William’s suggestions do not help, please check your web.config to see if you’re missing any configuration sections. On your local machine, when you install Enterprise Library, it may modify machine.config to add certain configurations. But they may not exist in the cloud. So please search your local machine.config to see if there’re any Enterprise Library specific sections, and then add them to your web.config.
Best Regards,
Ming Xu.