find a location for property in a new city
Showing posts with label IIS. Show all posts
Showing posts with label IIS. Show all posts

Thursday, 28 February 2013

The request filtering module is configured to deny a request that contains a double escape sequence

In IIS 7.5 I have a site that contains a page that takes an encrypted part of a URL. This encrypted string includes a plus sign '+' which causes IIS to throw a "HTTP Error 404.11 - Not Found" error stating "The request filtering module is configured to deny a request that contains a double escape sequence."

The problem is that a + sign used to be acceptable in earlier versions of IIS so these URLs need to remain for legacy reasons. So, I need to make them allowed again in IIS.

The quick fix

This can be easily achieved with a simple web.config change:

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true" />
    </security>
</system.webServer>

This allows URLs to contain this plus symbol '+'.

The warning

There are consequences to this which unsurprisingly are security related so please read Double Encoding to familiarise yourself with the risk for your situation. If it is a risk to you maybe the best solution is to redesign those URLs?

Follow britishdev on Twitter

Friday, 13 January 2012

Case sensitive Azure storage

Azure storage URLs are case sensitive as you may have noticed. If you have not noticed then: OMG AZURE STORAGE URL ARE CASE SENSITIVE!!1! This is most likely because URL specification states that URLs should be case sensitive so as to ensure different casings should represent different locations. Admittedly, this is rather odd when compared with IIS and subsequently web sites running in Azure.

I am a developer and architect by trade so I am more than aware of the importance in maintaining consistent URLs throughout a web site. Search engines index sites in a case sensitive way and so it is important not to accidentally display duplicate web content on differently cased URLs. To handle this in the past I have always insisted that my teams adopt a lower case policy where by every URL written in code, links, references etc are always written in lower case. This avoids such an SEO disaster. I also create a redirect rule using IIS Rewrite Module to 301 redirect any URLs containing uppercase characters to its lowercase version.

With this policy in mind it should not be difficult to now use Azure storage by simply maintaining these standards. It is wise to create a repository class that will handle all interaction with Blob, Tables and Queue storage that can abstract common rules away from the developer each time they wish to use them. One of these rules would be to ensure that when saving to these repositories the filenames and containers are lower cased using .ToLower() (in C#). Also when getting an object from storage you could also ensure that the file name requested is also lower cased in the same way.

This does not however prevent users accessing the URL using uppercase but really according to the URL specs they should not and using smart code you can most likely avoid this from happening. For example, if links are only ever displayed in lowercase someone if very unlikely to ever access it using uppercase.

Azure case sensitivity conclusion

So in summary, although it is an odd inconsistency between IIS and storage it is only a trivial programming exercise to enforce and a minor coding standard to communicate to your team. This will ensure that storage is always used as intended allowing you to reap the great benefits of using Windows Azure Storage.

Follow britishdev on Twitter

Saturday, 7 January 2012

Do not use iisreset in Azure

So you have remote desktop in to one of you Azure instances and you are free to do anything you like right? Wrong! Do not change things! And as I found do not use IISReset.

I have heard many times that remoting in to an Azure instance is for looking and debugging only, NOT for changing things. In fact I have even given this advice to many clients I have spoken to about Azure. But who am I to practice what I preach?

Really, I give the advice of not changing things when RDPing into an Azure instance because any changes you make will at some point be lost when your instances are automatically updated for you and then redistributed to other machines. Any changes you wish to be permanent on your machine will need to be part of your package.

Anyway, you can see why I avoid making changes, because of a lack of persistence but that doesn't mean I shouldn't do a cheeky IIS reset when trying to fix an issue right? Hmm, wrong.

Do not restart IIS on an Azure instance

I do not know why, there must be some black magic Azure voodoo that goes on after IIS is initialised that doesn't happen when you restart it yourself manually. Anyway, I learnt that it will completely destroy your instance. The site will not respond any longer from that instance. The best way to effectively do an IIS Reset is to Reboot your instance from the Azure Management Portal.

Follow britishdev on Twitter

Thursday, 20 October 2011

Unable to remove directory. Access to the path 'mswasri.dll' is denied when packaging an Azure project

When trying to build a package using the Azure SDK built into Visual Studio 2010 I sometimes get the error message "Unable to remove directory "bin\Release\CloudPackage.csx\". Access to the path 'mswasri.dll' is denied."

This stopped me from being able to build Azure cloud package ready for deployment. I tried changing my cloud package .csx file to read only but it just changed back. I tried deleting it but it was in use.

This gave me a clue. I run my local copy of my Azure site through my local IIS. I think this was locking the site and thus preventing it from being packaged.

Solution

The way to solve this problem that I found to work best was to find the Application Pool that is running the web application in my local development environment and stop it. This allows me to successfully package my web application ready from deployment to the Azure cloud!

Follow britishdev on Twitter

Friday, 9 September 2011

Not running in a hosted service or the Development Fabric - Azure

I got an InvalidOperationException with message "Not running in a hosted service or the Development Fabric" while trying to access my Azure site hosted on my local IIS. I have encountered this before and solved it but this time it confused be further so I thought this time I should document it.

The cause of this issue is that you are not running you Compute Emulator or your Storage Emulator. You can get these when you download and install the Windows Azure SDK (currently at v1.4). Once you have these you must have them running and, according to Michael Collier's blog post, they must be running as administrator too.

This can be done in two ways:

  • Going to Start > All Programs > Windows Azure SDK v1.4 > Compute Emulator and run it as administrator (which I can't find how to do).
  • Run the site in debug mode. This will cause the emulators to start running (since Visual Studio is running as administrator). Your IIS hosted site will then also be able to run.

I found the first way didn't work but that was because I didn't know I had to run them as administrator before I read Collier's post. However, after reading it I still can't figure out how to run it as administrator without using Visual Studio.

So usually I hit F5 to start debugging in the 127.0.0.1:{random port} page that starts up. I then close that window and continue using my IIS hosted site now that the emulators are running as administrator.

I have found one further complication though on the odd occasion. It seems that if you attempted to run your site before you had the emulators running, got the error and then started the emulators, you would still get the error. When this happens I found if I restart my site and application pool in IIS manager it will begin to work with the already running emulators correctly.

Conclusion

I now believe that you must have your Azure Compute Emulator(s) running as administrator before your site and application pool start up to run an Azure site successfully in IIS in a development environment.

Follow britishdev on Twitter

Friday, 18 March 2011

Firefox loses Request headers after redirect

Firefox does not remember some request headers after a redirect. This can cause problems with AJAX requests that use the X-Requested-With: XmlHttpRequest header.

I noticed a little problem with Firefox. In my scenario I have added the SEO optimising IIS Url Rewriting module pattern that redirects URL with upper case in to a lower case version.

For all browsers the AJAX request comes in with the X-Requested-With: XmlHttpRequest request header, a 301 status code is returned with the lower cased location, that new location then is requested with the X-Requested-With: XmlHttpRequest header in tact.

Firefox, however, does not honour this header in its redirect. This causes problems with my ASP.NET MVC code that checks for the request being via AJAX using IsAjaxRequest(). This method checks if X-Requested-With: XmlHttpRequest is in the headers (or in other exciting places).

Work around

I was going to try and do something clever like detect the browser and this header and then not redirect under some circumstances because (brace yourself SEO consultants) functionality is more important than SEO. I decided to instead make sure that one troublesome link was lowercase and so avoided the redirect.

Just hope this answers your questions if you come across this oddity in Firefox.

Follow britishdev on Twitter

Wednesday, 23 February 2011

SEO Redirecting URLs to lowercase excluding static files

As you may know Google treats different cased URLs as different URL entirely. If they find both cases they will judge this as duplicate content so it is a good idea to redirect requests for a URL containing uppercase to lowercase.

This is made easy with the URL Rewriting Module 2.0. You can use the "Enforce lowercase URLs" template to do most of the work for you.

This will create a pattern match of [A-Z] (as in if there is even one capital in the URL) it will 301 redirect to {ToLower:{URL}} which is fairly obvious what it does.

What about static resources files?

You don't really want these redirects to happen since you don't really want search engines to index them so it takes up needless resource. Also, for my particular set up it fails to send them (some sort of weird, secure + load balanced + redirecting issue).

  1. Open the Conditions section of your lowercase redirect rule and click Add...
  2. Set Condition input to {URL} (which doesn't look at any querystrings).
  3. Set Check if input string to Does Not Match the Pattern
  4. Change the Pattern field to one that suits you. I have used ^.+\.(axd|gif|jpg|jpeg|png|css|js|svc|ashx)$ since I do not what files with these extension redirected. You may have more. Or less
  5. Ignore case should be checked
  6. Click OK and Apply your new rule

Your site should now send www.mysite.com/Home/Index to www.mysite.com/home/index with a permanent 301 redirect and leave www.mysite.com/WebResource.axd alone.

Follow britishdev on Twitter

Monday, 14 February 2011

Working solution breaks on new machine. IIS setup with URL Rewrite Module

A solution that works fine on one machine will not work on a different development machine. I just received a 503 service unavailable error and the IIS rewrite module was giving an error saying "There was an error while performing this operation" and "Unrecognized attribute 'trackAllCaptures'"

When I get a massive IIS style, 'light blue screen of death' error message it is usually something to do with web.config not recognising some attribute. Clicking about the various modules in my site through IIS I soon discovered that it was the URL rewrite module specifically I was having problems with. It was saying that trackAllCaptures was an unrecognised attribute.

It was complaining about not recognising a particular node. This was because I hadn't got IIS URL Rewriter installed on my new machine. Installing it works a treat!

Follow britishdev on Twitter

Thursday, 6 January 2011

Enable assembly bind failure logging using Fusion

I got a FileNotFoundException with an error message of 'Could not load file or assembly 'LoveMoneyHttpModules' or one of its dependencies. The system cannot find the file specified.' This doesn't help much but does give some advice on enabling assembly bind failure logging.

The advice is to turn on the assembly bind failure logging but gives a tip of setting the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

That's not very friendly advice so the question is how to do that exactly. I found a nicer way to do it than messing with the registry. First, you need to open the Fusion Log Viewer tool. You can do this by opening a Visual Studio command prompt and running fuslogvw.exe or alternatively just type Fusion Log Viewer into your Windows search bar thing.
  1. Open Fusion Log Viewer
  2. Click 'Settings...' and select the 'Log in exception text' radio button. Click 'OK'
  3. Do an IISreset.
The IIS isn't meant to be part of it I just found that it wasn't working until I tried that too. Anyway, after that I started getting logs of the attempts at binding in my yellow screen of death.

Follow britishdev on Twitter

Thursday, 18 November 2010

How to host multiple secure sites in IIS

I have two sites: www.site1.com and www.site2.com. Both have pages that are served securely and so need a binding for https on port 443.

The problem is that only one site can be bound to the https protocol and if I disobey that rule I get strange behaviour such as requests for site1 actually serving the page from site1.

How to host multiple secure sites on your local IIS

First, you should know that sites resolve which site to bind to based on:
  • Host header e.g. local.www.site1.com
  • Port e.g. 443
  • IP adress

In this scenario I really just want to change the host headers of the two https bindings for the different sites but IIS won't let me. But I have ways of persuading it...

Step 1:
Navigate your way to C:\Windows\System32\inetsrv\config where you may or may not see applicationHost.config. This is a very mysterious file, it's there but not, sort of. I've found that it can be edited in NotePad (but nothing else(?))

Step 2:
Ctrl+F your way to "443:" and you should find your attempted 443 http bindings. In my case there are two and they both look like <binding protocol="https" bindingInformation="*:443:" /> (Oh yeah they are exactly the same, lets change that.

Step 3:
Change them to <binding protocol="https" bindingInformation="*:443:local.www.site1.com" /> and <binding protocol="https" bindingInformation="*:443:local.www.site2.com" /> respectively.

Job done

If you check in your IIS UI you will notice that you host headers have indeed been set and your sites should now be able to discriminate between the two.

Follow britishdev on Twitter

Thursday, 12 August 2010

Remove HTTP response headers to hide your framework

There are a number of infrastructure details that are passed with your HTTP response headers when serving a page. The security conscious developers out there will be aware that hackers and other malicious people will enjoy learning that information to target their exploits for that framework. If you want to remove the HTTP response headers of Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version or any others I will show you how.

I will show you the less hacky ones first. I.e. the ones where it is designed for you to remove them easily:

X-AspNet-Version

This can be removed simply using the enableVersionHeader attribute of the httpRuntime section of system.web section of your web.config:
<system.web>
  <httpRuntime enableVersionHeader="false" />
  <!-- other settings -->
</system.web>

X-AspNetMvc-Version

In your Global.asax.cs you can add the following to your Application_Start method:
protected void Application_Start(object sender, EventArgs e)
{
    MvcHandler.DisableMvcResponseHeader = true;
    // RegisterRoutes etc... and other stuff
}

X-Powered-By

Instead of removing this I have decided to change it to something different so as not to cause suspicion to a potential hacker:
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By"/>
      <add name="X-Powered-By" value="PHP 5.2 Ubuntu"/>
    </customHeaders>
  </httpProtocol>
  <!-- other stuff -->
</system.webServer>

Server

This one is harder since you can't actually do it anywhere else. Of course you could have changed all the other Headers here too but it feels messy doing it this way so I opted to change the others using the intended way.

First, make an HttpModule (essentially a class inheriting from IHttpModule) like this:
namespace HttpModules
{
    public class SecurityModule : IHttpModule
    {
        public void Dispose()
        {
            //intentionally do nothing
        }

        public void Init(HttpApplication context)
        {
            context.PreSendRequestHeaders += new EventHandler(context_PreSendRequestHeaders);
        }

        private void context_PreSendRequestHeaders(object sender, EventArgs e)
        {
            var context = ((HttpApplication)sender).Context;
            context.Response.Headers.Set("Server", "Apache 2.0");
        }
    }
}
Note: I have gone for lying about the server over removing it (which is also possible) since I'd rather fool hackers than annoy them.

Next you just need to register that module in your web.config:
<system.webServer>
  <modules>
    <add name="SecurityModule" type="HttpModules.SecurityModule, HttpModules" />
  </modules>
</system.webServer>

Now use Fiddler to have a look at your Response Headers. Hopefully wonderfully deceptive like this:

If you have more to remove/change you can do it in much the same way as X-Powered-By (using web.config) or if not the Server one (using the Security HttpModule).

Follow britishdev on Twitter

Friday, 4 June 2010

Don't use runAllManagedModulesForAllRequests="true" when getting your MVC routing to work

It seems to be common advice to make your modules section of your web.config say <modules runAllManagedModulesForAllRequests="true">. In fact this is quite a drastic thing to do to solve the routing problem and has global effects that could CAUSE ERRORS.

You need a module that goes by the name of UrlRoutingModule-4.0 to be running through IIS. Now, since your MVC URLs are likely to end without .aspx these will not be picked up by IIS and run through the intergrated pipeline and therefore you will end up with 404 not found errors. I struggled with this when I was getting started until I found the <modules runAllManagedModulesForAllRequests="true"> workaround.

This highly recommended fix can cause other problems. These problems come in the form of making all your registered HTTP modules run on every request, not just managed requests (e.g. .aspx). This means modules will run on ever .jpg .gif .css .html .pdf etc.

This is:
  1. a waste of resources if this wasn't the intended use of your other modules
  2. a potential for errors from new unexpected behaviour.

Better solution

Fine, so the ranting about <modules runAllManagedModulesForAllRequests="true"> is over. What is a better solution?

In the modules section of your web.config, you can add the UrlRoutingModule-4.0 module in with a blank precondition meaning it will run on all requests. You will probably need to remove it first since it is most likely already registered at machine level. So make your web.config look like this:
<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>

Note: the modules element does NOT contain the runAllManagedModulesForAllRequests="true" attribute because it is evil!

Follow britishdev on Twitter

Thursday, 29 April 2010

Error in Silverlight application code: 2104 Could not download the Silverlight application. Check web server settings

Setting up a Silverlight application for the first time I got a JavaScript error of "Unhandled Error in Silverlight Application Code: 2104" with an accompanying message "Could not download the Silverlight application. Check web server settings"

Being new to this and largely just experimenting with Silverlight for the first time wasn't 100% what to do. At least it pointed me in the right direction with its "Check web server settings" comment at the end.

I checked the MIME types for my site. Sure enough there was no mention of the .xap extension. Yes, that would be the problem.

Solution

I added a MIME type with extension ".xap" and MIME type of "application/x-silverlight-app" and it all worked pleasantly.

I thought this was a bit weird that it didn't come pre-registered but oh well, hope you find this useful.

Follow britishdev on Twitter