Rewrite Maps in IIS Make web.config Too Large - iis-7

I am migrating a website which is/will be running on IIS and I will be using rewrite maps to 301 redirect old ".asp" URLs to a new style of URL. For many thousands of URLs there is no pattern, so it appears I must rely on rewrite maps.
My problem is that the default web.config size limit is 250kb, and in my environment, I don't have access to change this (as can be done at the registry level - if one had access).
I have looked into moving the rewriteMaps section to an external file, but the external files also have the default size limit of 250kg, so this is also not going to work.
I am looking for some other way to handle this... I am sitting at 242kb currently and have over twice the amount of old to new redirect mapping to add.
Thanks in advance.

As I am in a shared environment, there was no solution other than to move it to a single external config file, which was again, limited to 250KB.
So here is what I did:
I filled up the map to capicity with the highest-trafficked redirects and of course any groups of urls that could be redirected using a pattern (so they would be fastest).
For the 100k remaining long-tail of the redirects, I put them into a REDIRECTS table in the db... SO, after the request passes all of the rewrite rules in the file (and of course, doesn't hit any), it defaults the request to a certain script. One of the first things the script does is check the REDIRECTS table, and if an entry exists, I do a redirect in the code... it's slower, but most of the stuff in the table is long tail, and as I said, the most visited redirects are still in the file. This has worked well for me so far, and I can add as many redirects as I want... e.g. if a page title/url gets edited, my admin area automatically adds the redirect, etc.

The Nativerd.dll file uses the value of this registry key to determine the maximum allowed size, in KB, of the Web.config files. The Configuration system assumes a default value of 250 KB in Windows Server 2008 and 100 KB in the release version of Windows Vista.
The reason for the 250KB limit is to reduce attacks for uploading a large web.config file. You can change the the limit by altering the upper value in your registry:
HKLM\SOFTWARE\Wow6432Node\Microsoft\InetStp\Configuration\MaxWebConfigFileSizeInKB (REG_DWORD)
See: Description of the registry keys that are used by IIS 7.0, IIS 7.5, and IIS 8.0
Another option is to split your web.config files into multiple smaller files.

We were stuck on this for a long while, we ended up writing our own 301 redirector. In sitecore it was in a pipeline patched after ItemResolver which consumes the large file (not included in any Web.configs). We could not use the "registry hack" option as it an Azure Service App and there is no (easy and cheap) access to the registry.

You can split up your configuration into a few different files as Neill said.
You will have a main web.config file in which you’ll reference sub config files by adding a configSource attribute onto the sections you would like to split into other files.
For example, if you’d like to split the section “appsettings” in another file, you would change the appSettings section in your web.config file to :
<appSettings configSource="appsettings.config" />
and in the appsettings.config file, you would add all your appsettings entries like they were in the original web.config file, for example;
<appSettings>
<add key="aspnet:RestrictXmlControls" value="true" />
<add key="FeedCacheTime" value="300" />
<add key="FeedPageUrl" value="/_layouts/15/feed.aspx?" />
<add key="FeedXsl1" value="/Style Library/Xsl Style Sheets/Rss.xsl" />
<add key="aspnet:AllowAnonymousImpersonation" value="true" />
</appSettings>
Obviously with the rewrite maps instead.

Related

Can included sections in Web.config be encrypted

I have an ASP.NET MVC5 website in development which I will shortly need to deploy to an IIS8 webserver. I'm trying to get the security model for the web.config file right, and in particular I want to:
Prevent secrets in the web.config file being exposed in my source control system
Protect the deployed web.config from prying eyes (I don't own the server).
From searching on SO and other sites I can see that there are specific tools/techniques to address each scenario:
'Included' sections in web.config that do not get saved to the SCCS.
Encrypted web.config files. Or encrypted sections of the file to be more precise.
I'm fine with both of those, but I can not for the life of me see how to combine the two techniques to solve both problems simultaneously. Is it possible to encrypt an external section? Is this even the right approach given that many of the answers are several years old now and address older versions of ASP.NET/MVC.
I can't be the first do want to do this so I'm sure I'm missing something obvious.
It has been suggested that this might already be answered here, however that question is about encrypting sections in the main web.config file, and I am asking about encrypting external sections. By that I mean sections that are 'included' using the configSource XML attribute.
It's probably bad form to answer ones own question, but I had a flash of inspiration and after a couple of hours of experimentation I have it working how I want.
The bit I had got all wrong was that I was trying to encrypt the external files. It does not work like that. Here's how it does work, at least, this is how it works for me on an IIS8.5 and ASP.NET v4.0.30319 server.
ConnectionStrings
Create the connectionStrings section in a separate file, e.g. Web.connectionStrings.config:
<?xml version="1.0"?>
<connectionStrings>
<add name="MyConnection" connectionString="{your connection string here}"
providerName="System.Data.SqlClient" />
</connectionStrings>
Ref this file from web.config:
<connectionStrings configSource="Web.connectionStrings.config" />
Make sure the external file is not under source code control so it does not get uploaded to your SCCS.
Deploy BOTH files, either as part of your deployment process or deploy the secure file manually if you're really paranoid.
Encrypt the connectionStrings section of the web.config normally, using the aspnet_regiis.exe command mentioned in the article mentioned by Afzaal. This process actually encrypts the contents of the Web.connectionStrings.config file and leaves the web.config file unchanged. You need to leave the external file in place but as it is now encrypted this is quite safe.
appSettings
Create your security-critical settings in a separate file, e.g. Web.appSettings.config.
<?xml version="1.0"?>
<appSettings>
<add key="wc1" value="web.app.config1" />
<add key="wc2" value="web.app.config2" />
</appSettings>
Ref this file from web.config:
<appSettings file="Web.App.config">
{other non-secure appSettings}
</appSettings>
Again, ensure the secure file is not under source control, and deploy both files to the production server.
Encrypt the appSettings section of the web.config file.
Unlike the connectionStrings section, this does not alter the external file at all. Instead, settings from both web.config and the external file are merged (external file takes precedence if duplicate keys are encountered) and are stored in an encrypted form in web.config.
At this point you can remove the Web.appSettings.config file as its contents are now incorporated into the main file.
Points to note:
If you introduce another Web.appSettings.config file at a later time, and restart the site, the contents of that file will override the encrypted settings in web.config. This may or may not be useful. When you remove the file and restart the site, the settings revert to the encrypted ones again.
If you decrypt the appSettings section, ALL the current settings are written back into the main web.config file, including those that originally came from the external file. You'll need to remember to remove them if you're just changing a setting and then re-encrypting the file again.

How to set cache headers for files accessed directly

I have a server that serves WAV file to Twilio and I am having some problems to set the cache to those files.
My problem is that the files have different expiration date, some shouldn't be cached, some should be cached for a day, some for a month and so on.
At the moment I was able to set to not cache any of the files using the IIS Output Caching, however now I need to set some caches.
Basically Twilio request the WAV files calling it directly, for example, http://mywebsite.com/mysoundwithoutcache.wav as well as http://mywebsite.com/mysoundwith1daycache.wav and so on.
My question is how do I add this headers to those files that are been called directly?
I am using IIS 7 and ASP.NET
Thanks in advance
The way to apply settings just to a certain files is to use the location tag, in your web.config add a new node under configuration:
<location path="cache_me.wav">
<system.webServer>
<caching>
<profiles>
<add extension="*.wav" policy="CacheForTimePeriod" kernelCachePolicy="DontCache" duration="01:00:00" />
</profiles>
</caching>
</system.webServer>
</location>
Unfortunately I don't think you can use wildcards in the path attribute, so you one of these sections for each file. If would be easier to put all files to be cached into a separate folder, then you can get away with a single location node.
Having said all that, you should not worry about output caching for your waves files, static files are cached by IIS automatically.

urlrewritingnet - rewrite URL with subdomain

I have umbraco website setting on an IIS 7 server: WWW.SITE.COM
I would like rewrite the URL WWW.SITE.COM/SIGUNP to WWW.SIGNUP.SITE.COM
is it possible by using urlrewritingnet or should I configure this by using DNS Host?
I would use HTTP Redirect in IIS to achieve this. I'd recommend using permanent (301) as response status, this will also force most search robots to update their indexes.
Add everything inside the configuration elements to your web.config file
<?xml version="1.0"?>
<configuration>
<location path="signup">
<system.webServer>
<httpRedirect enabled="true" destination="http://www.signup.site.com" exactDestination="false" httpResponseStatus="Permanent" />
</system.webServer>
</location>
</configuration>
exactDestination="false" will turn http://www.site.com/signup/anything/example.html into http://www.signup.site.com/anything/example.html
exactDestination="true" will turn http://www.site.com/signup/anything/example.html into http://www.signup.site.com/
There are several approaches to doing this and Eric's approach is a perfectly valid one. You can also use UrlRewriting.Net as you suggest but I think Eric has suggested the baked in <httpRedirect /> approach as it can be configured in the web.config and therefore also in IIS7 manually.
The disadvantages to this approach however are that:
It needs a developer to update the web.config; or
Someone with access to IIS to change the configuration
It requires an application restart to pick up the redirect rules
There are two other approaches you should consider:
A HttpModule that uses a CSV file containing a cached list of 'from' and 'to' URLs;
A Umbraco-managed doc type that can handle specific path redirects.
The HttpModule approach obviously requires a little coding but is very rewarding. Your SEO team/client can provide a list of URLs that need redirecting and your HttpModule can cache the list (using the file as a dependency) and perform the redirects based upon matched URLs. Any update to the file simply clears the cache automatically.
For basic redirects, I like the approach of having a "Redirect" doc type in Umbraco. This doc type will have two fields, a "redirect type" field (301/302) and a "redirect to" field. In the template for this doc type you will need a little cpde that performs a redirect to the "redirect to" node. Any hits on a page created using this doc type will automatically redirect to the target page. You can also use this doc type in conjunction with "umbracoUrlAlias" field. You can add multiple paths to this field separated by a comma (see this article for an explaination). This way you can catch multiple simliar paths and redirect to a single path.
The advantage of this approach is that it is manageable in the CMS, but the disadvantage is that the redirects are not managed centrally like a CSV file, so you need to be careful in how it is implemented.

File size upload limit in Orchard CMS Media

I'm using the Media module to upload a file in Orchard. If I select a file of 2.2MB it works, however if I try to upload a bigger file (let's say a 4MB movie) I get an error page saying that 'This page is not available'.
Is there a size limit and if yes how can I increase it?
Thanks!
You can set that in root Orchard Web.config file (it's in the Orchard.Web project if you are working with the full source). By default ASP.NET has a 4MB limit for size of POST request.
<system.web>
<httpRuntime maxRequestLength="1024000" executionTimeout="360"/>
</system.web>
Above will set max request size to 1 GB.
You can read more about that here, here and here.
An additional note to Piotr's answer: maxRequestLength's value is in KBs, so maxRequestLength should be 1024000 for a GB (the answer above shows 102MB).
For those using Azure and the ClickToBuildAzurePackage.cmd from the source: You'll need to modify the src\Orchard.Azure\Orchard.Azure.Web\Web.config file with maxRequestLength. This is because the packager will overwrite the Web.config in the src/Orchard.Web/Web.config with this file. Or technically you can make the build and modify the web.config file after and repackage, but I personally haven't gotten Azure to successfully take my "rezipped" package.
When uploading large files to Orchard via http over ADSL, another setting that I needed to change was the connection timeout, which has a default of 120 seconds. This seems to override the settings discussed here and caused the connection to be reset. In IIS7 this is under the 'Limits...' section on the right hand side, for the specific site node, or 'set Web Site Defaults...' on the sites node.
The config section is:
<system.applicationHost>
<sites>
<siteDefaults>
<limits connectionTimeout="00:20:00" />
</siteDefaults>
</sites>
</system.applicationHost>
See also iis.net documentation

Is web.config or app.config cached in memory

if it is cached, what happens if I use multiple web.config in multi-level folders
They all get cached.
Configuration is read once, at startup. With web.config, IIS watches for file changes and restarts the application.
OK, so ya'll are missing a KEY feature in the Web.Config file's area.
Yes, web.config is cached and changing contents of the file will restart your web app. And, all your connected users will not be happy, too, because they'll need to "reconnect" a-new, possibly losing desired information.
So, use an EXTERNAL custom file for your AppSettings, as follows:
<appSettings configSource="MyCustom_AppSettings.config"/>
Then, in the file MyCustom_AppSettings.config file, you have your settings, as such this example has:
<appSettings>
<!-- AppSecurity Settings -->
<add key="AppStatus_Active" value="Active"/>
<!-- Application Info Settings -->
<add key="AppID" value="25"/>
<add key="AppName" value="MyCoolApp"/>
<add key="AppVersion" value="20120307_162344"/>
</appSettings>
Now, if you need to add, change, or remove an AppSetting, when you change it in this file the change is nearly instant in your web-app BUT (and here's the BEST part), your app DOES NOT RESTART!
Everything stays kosher except those settings you've added/modified/removed in the external .config file.
And, yes, the same thing can done for the section as follows:
<connectionStrings configSource="MyCustomApp_ConnectionStrings.config"/>
and the file MyCustomApp_ConnectionStrings.config has all the connection strings you need. Change a connection string in the external .config file and it starts getting used right away and with no web-app restart.
The configSource setting(s) are great when you need to deploy to development, testing, and production on different boxes and need settings pertinent to that given box/environment.
So, now ya know (something that's been around for 7+ years).
It's That Simple. Really.
KC
Web.config (excluding external config files) is read when the application loads. Some config settings have a cascading behavior. For example, the system.web/authorization section can be overridden by configs at deeper levels.
ASP.NET monitors the web.config for changes. When it changes, the web application is forced to restart. Moral is that web.config settings are cached for the life of the application.

Resources