Archive

Posts Tagged ‘.net’

FormRewrite.dll

July 7th, 2006

For those of you who love dabbling with rewriting URLs, you have most probably become aware that Dot Net 2.0+ handles postbacks and viewstates differently to Dot Net 1.x. The action attribute within the form tag sends postbacks back to the physical page, and not the rewritten page, causing a viewstate validation error due to the tighter security of the second framework.

This is not a big problem however. To solve this, all we need to do is rewrite the location of the action attribute to the rewritten url. If you can do this, great, but an easier solution is to leave the action attribute blank, which has the effect of sending the form back to the same page - Excellent, that’s what we want, with hardly any effort. ;)

Firstly download FormRewrite.dll and place in your bin directory (Legacy - Currently unavailable)

Secondly we need to rewrite the form’s action attribute; place this code into every page that is rewritten and perform postbacks. If you use master pages, place it in there instead.

Add to the first line of your file

Imports Denaploy.Sys.Rewrite

And this within your class

  Protected Overrides Sub Render(ByVal writer As System.Web.UI.HtmlTextWriter)
    writer = New FormRewrite(writer, " ", HttpContext.Current.Items("VirtualPath"))
    MyBase.Render(writer)
  End Sub

Techie ,

IIS Application Mapping

May 8th, 2006

‘Applications Extensions’ in IIS allows you to bind file extensions to ISAPI’s (for example the dot net framework). This allows you to create unique extensions for your applications, instead of using the traditional ‘.aspx’.

(IIS 6.0 was used at the time of writing this article. Unfortunately to date I haven’t been able to get this working on IIS7)

Example Use

There are several examples of where I have needed to use this. I tend to use it either to increase search engine optimisation through rewriting urls, or to add simple yet effective commands to users or administrators in the form of extensions (’.add’, ‘.delete’, ‘.edit’, ‘.move’ etc)

I’ve recently created a website which moderators can easily add or modify pages in a wiki type style. For ease of editing pages, and to not advertise to the rest of the world, all you need to edit a page is to add ‘.edit’ to the end of the URL.

If you are playing with ModRewrite, you will find binding wildcards can really prove invaluable. It allows you to completely remove the ‘.aspx’ at the end of the url, and replace it with any other extension you like, or remove it altogether like on this wiki.

Adding Application Extensions

In order to register custom extensions with IIS and allow it to pass these requests to the dot net framework, or any other ISAPI, you will need to do the following:

  • In IIS Manager, load up the properties page on the website in question.
  • Select the ‘Home Directory’ tab
  • Click on ‘Configuration’ to obtain the ‘Application Configuration’ dialog
  • Under Mappings, click ‘add’ to allow you to enter an alternative extension
  • Executable should be the dot net isapi, which is typically located as follows:

c:\winnt\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll

  • Extension, well, the extension you wish, starting with a period.
  • If this is a dynamic page, ie, the page doesn’t actually exist on the server, but is handled at runtime, un-tick ‘verify that file exists’

IIS should now send the request to the framework, and you should be able to catch it within your application and deal with it however you see fit.

Wildcard application maps

If you have multiple extensions, or simply wish to remove the extension altogether, adding a wildcard will pass any requests not caught by the above mappings into the framework. This is extremely handy when rewriting urls.

Click insert, and add the isapi you require. When rewriting urls, you certainly want to un-tick the ‘Verify that file exists’ option to prevent a 404 from occurring; the physical file is called and probably located somewhere completely different.

Techie ,

ModRewrite For .Net Applications (prior to iis7)

February 3rd, 2006

One thing web developers from linux backgrounds really miss in windows is using modrewrite to rewrite urls. In dot net, this is actually a tad trickier, especially with the new asp 2.0.

One solution is to use a DLL produced by ThunderMain, called URLRewriter. Because this solution requires the Dot net framework to process the rewriting of URLs, a wildcard has to be setup within IIS to allow all extensions to be processed by the dot net framework. The disadvantage over this is legitimate requests for files, such as images or html documents, will be routed through your application and hence exceptions will have to be made.

Once URLRewriter has been setup correctly for your application, you may notice that form post backs actually get posted back to the original and not the rewritten location. This is only ugliness for 1.0-1.1, but in 2.0+ it has a more terminal impact of causing the page’s viewstate on postback to not match that of the original rewritten url, resulting in a viewstate error. Changing the action of the form can be a right pain, as dot net really doesn’t take kindly in altering things behind its back. To correct this problem, there’s a nice DLL I have written to change the form action to whatever the current rewritten URL is. (legacy - currently unavailable)

Installing URLRewriter

Download the dll, and add a reference within your project. Within global.asax.vb we need to call the rewriter at the beginning of each request

    Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
    	' Fire the URL Rewriter Fires at the beginning of each request
    	ThunderMain.URLRewriter.Rewriter.Process()
    End Sub

Add the following code into the relevant location within the Web.Config

<configuration>
  <configSections>
      <sectionGroup name="system.web">
          <section name="urlrewrites" type="ThunderMain.URLRewriter.Rewriter, ThunderMain.URLRewriter, Version=1.0.783.30976, Culture=neutral, PublicKeyToken=7a95f6f4820c8dc3"/>
      </sectionGroup>
  </configSections>
</configuration>

The rewrite rules are set within the Web.Config, as shown. They are formatted as standard regular expressions, as modrewrite is.

<system.web>
  <urlrewrites>
    <!-- switches .html to .aspx -->
    <rule>
      <url>^(.*)\.html$</url>
      <rewrite>$1.aspx </rewrite>
    </rule>
    <!-- Rewrites “Geeky/12-ModRewrite.aspx” into Default.aspx?ID=12&Category=Geeky&PageTitle=ModRewrite -->
    <rule>
      <url>(.*)/([0-9]+)-(.*)\.aspx</url>
      <rewrite>Default.aspx?ID=$2&Category=$1&PageTitle=$3</rewrite>
    </rule>
  </urlrewrites>
</system.web>

From the above rules, you can see the benefit of rewriting query strings to look like directories and physical files. Not only does it make it easier for people to type the address into their browser, but it also is a help in getting large sites indexed by search engines. If your URL has a large amount of query strings, search engines may not index the whole range within the site, however, by rewriting the URLs, it appears that each of the pages in fact originate from individual files.

Techie ,