I faced this problem earlier today. Thankfully (as is usually the case) it was simple to resolve.
If you face this problem with an httphandler (usually .axd extension), make sure you have added a new "system.webServer" section to your web.config file. Yes, that's right, IIS7 doesn't look at the old httpHandlers and httpModules conig sections in system.web. You will need to copy your these sections into the new system.webServer section.
But wait, there's more! What caught me out today was the fact that IIS7 needs to see a name attribute in each "add" element. I am using a third party captcha on one of my sites - Lanap Botdetect. After puzzling over a 500.19 server error about incorrect configuration, I realised that IIS7 was expecting to see a name attribute, so I simply added name="LanapCaptcha" to the element (see below). Problem solved. I you have any specific questions related to httphandler problems, post them in the comments section below and I'll try and help you. If this post helped you, please Digg it using the Digg button at the top!
</system.webServer>
...
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="LanapCaptcha" path="LanapCaptcha.aspx" verb="*" type="Lanap.BotDetect.CaptchaHandler, Lanap.BotDetect" />
<add name="ASBXHandler" verb="GET,HEAD,POST" path="*.asbx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</handlers>
</system.webServer>
Friday, 12 March 2010
Monday, 8 March 2010
The power of the IIS7 url rewrite module
Having only recently got into IIS7 after buying a new web server, I am pleased to see that version 7 is somewhat following apache's lead by allowing modules to be plugged into the server. If you host anything beyond a very basic website in IIS 7, you will likely have the need to use http modules, very likely including some kind of url rewiting.
There can be many reasons to do url rewriting - Search Engine Optimization (friendly urls), Redirection to a secure site, or changing the request in some other way.
With IIS 6 you would either have to pay for a 3rd party ISAPI dll to do some of these, or spend time programming them yourself. But now the IIS 7 url rewrite module is here to come to the rescue.
All this involes is editing your web.config, using the new IIS7-only system.webServer configuration section (you can also do it through IIS Manager). Here are 2 examples.
The first rule I have created below redirects requests starting with "http" to the equivalent "https" url. You can do this for a specific area within your application too - just add another web.config within that subfolder with appropriate rules inside it's system.webServer -> rewrite section. You can also usetags if you want to keep all web.config stuff in one file. E.g.:
The second rule redirects requests not containing www (e.g.: http://yoursite.com) to the url containing www. You can do the opposite quite easily too.
<system.webServer>
...
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
There can be many reasons to do url rewriting - Search Engine Optimization (friendly urls), Redirection to a secure site, or changing the request in some other way.
With IIS 6 you would either have to pay for a 3rd party ISAPI dll to do some of these, or spend time programming them yourself. But now the IIS 7 url rewrite module is here to come to the rescue.
All this involes is editing your web.config, using the new IIS7-only system.webServer configuration section (you can also do it through IIS Manager). Here are 2 examples.
The first rule I have created below redirects requests starting with "http" to the equivalent "https" url. You can do this for a specific area within your application too - just add another web.config within that subfolder with appropriate rules inside it's system.webServer -> rewrite section. You can also use
<location path="admin"><system.webserver><rewrite>... your rules...</rewrite></system.webserver></location>
The second rule redirects requests not containing www (e.g.: http://yoursite.com) to the url containing www. You can do the opposite quite easily too.
<system.webServer>
...
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<!-- Require SSL must be OFF in the site settings -->
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}{REQUEST_URI}" />
</rule>
<rule name="Non www to www redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.yoursite\.com$" ignoreCase="true" negate="true" />
</conditions>
<action type="Redirect" url="https://www.{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
See also the official documentation for the IIS7 url rewriting module.
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}{REQUEST_URI}" />
</rule>
<rule name="Non www to www redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.yoursite\.com$" ignoreCase="true" negate="true" />
</conditions>
<action type="Redirect" url="https://www.{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
Wednesday, 10 February 2010
Alternative to on delete cascade in sql server
I'm working with a modified asp.net database, a partial diagram is shown here.
I discoved that Sql server management studio wouldn't let me put cascade delete rules on all the relationships. Unfortunately this is a limitation of SQL server, but there is a way around it.
Simply set the delete rule of either the FK_B_aspnet_Users or FK_A_aspnet_Users to No Action, or delete one of the relationships altogether. Then create a delete trigger:
CREATE TRIGGER [trig_delUser]
ON [dbo].[aspnet_Users]
FOR DELETE
AS
delete B
from B, deleted
where B.UserId = deleted.UserId
Where B is the table joined by the No Action relationship, or where the relationship was deleted. (Note: you could make B->Linker the no action relationship, then create the delete trigger on B).
In this way, deletes over Users->A and A->Linker are automatically handled, with your trigger handling deletion of B entities when a user is deleted, with the B->Linker cascade taking care of the rest.
You can also do this using stored procedures, but this is my preferred method, as I think it is more flexible and easier to debug.
For very large deletion operations, things are a bit different. What you should do is write the deletes to the child tables first then the delete to the parent table, wrapping everything in a transaction - I'll explain that in another post. However, the above method will work perfectly well when you are deleting a few records at a time.
I discoved that Sql server management studio wouldn't let me put cascade delete rules on all the relationships. Unfortunately this is a limitation of SQL server, but there is a way around it.
Simply set the delete rule of either the FK_B_aspnet_Users or FK_A_aspnet_Users to No Action, or delete one of the relationships altogether. Then create a delete trigger:
CREATE TRIGGER [trig_delUser]
ON [dbo].[aspnet_Users]
FOR DELETE
AS
delete B
from B, deleted
where B.UserId = deleted.UserId
Where B is the table joined by the No Action relationship, or where the relationship was deleted. (Note: you could make B->Linker the no action relationship, then create the delete trigger on B).
In this way, deletes over Users->A and A->Linker are automatically handled, with your trigger handling deletion of B entities when a user is deleted, with the B->Linker cascade taking care of the rest.
You can also do this using stored procedures, but this is my preferred method, as I think it is more flexible and easier to debug.
For very large deletion operations, things are a bit different. What you should do is write the deletes to the child tables first then the delete to the parent table, wrapping everything in a transaction - I'll explain that in another post. However, the above method will work perfectly well when you are deleting a few records at a time.
Monday, 8 February 2010
Website performance optimization
These days, there are lots of tools out these to help optimise the loading times and performance of your websites. YAHOO even have a set of rules dedicated to helping you get the most out of your websites' performance:
YAHOO website performance optimization rules
If you don't have time to read through these rules, some clever person had the good sense the implement them in a Firebug plugin that you can run on your website:
YSLOW performance measurement firebug plugin for firefox
YAHOO website performance optimization rules
If you don't have time to read through these rules, some clever person had the good sense the implement them in a Firebug plugin that you can run on your website:
YSLOW performance measurement firebug plugin for firefox
Labels:
Debugging,
Web hosting,
website performance
Auto-remove SVN files with a shell command
I just found a .reg script to remove SVN files fith a shell command:
Click here to see it
I recommend you check out the other posts on the Lunar Media blog - some useful tips. I'm not affiliated with them in any way (just so you know ;))
Click here to see it
I recommend you check out the other posts on the Lunar Media blog - some useful tips. I'm not affiliated with them in any way (just so you know ;))
Labels:
svn
Tuesday, 19 January 2010
Subscribe to:
Posts (Atom)