Welcome to part 10 of my tour through ASP.NET 4.0. In this episode, we’re going to look at a few small but useful additions to the ASP.NET 4.0 webforms template engine before we head out into the wider world of the core framework – routing, caching, sessions and so on.

<asp:Chart> Now Built In

1_chart

We’ve seen before how Microsoft has folded features from ASP.NET 3.x and other out-of-band releases into the core ASP.NET 4.0 DLLs before. Case in point, the ASP.NET Chart control released in November 2008. This was based on Dundas Chart source code version 5.5 via a Microsoft security, accessibility, and API review. It’s now built into the core which means no additional web.config to get it running and an entry in the Data tab of the standard toolbox set.

Check out more info on the charting control here.

Three New Redirect Methods

The HttpResponse class has been fitted with three new redirect methods, two to work nicely with routing, which we’ll cover later in this series, and the other to play nicer with search engines. Response.RedirectToRoute and Response.RedirectToRoutePermanent are the two we'll note in passing for now. As you might suspect, these allow us to redirect users to a page at the end of a route we've defined rather than the page directly. The main difference between the two is that RedirectToRoute sends a HTTP 302 Found response back to the browser while ResponseToRoutePermanent sends a HTTP 301 Moved Permanently. To a user, both methods simply redirect their browser to a new page. To a search engine spider, 302 Found implies that the page has moved temporarily, so it will index both the old and new, temporary location. 301 Moved Permanently implies that henceforth the old location is not used and it will only index the new location going forward. 

The third new redirect method, Response.RedirectPermanent, also sends a 301 Move Permanently response, but redirects straight to a page rather than a route. It has two overloads like Response.Redirect.

  • RedirectPermanent(string url)
  • RedirectPermanent(string url, bool endResponse)

The first parameter is simply the URL of the page you wish to redirect to.

Response.RedirectPermanent(http://blog.hmobius.com);

The second parameter lets you specify whether or not ASP.NET should stop processing the page and move straight to processing the Application_EndRequest method in global.asax.cs if you have one.

Side note: There has always been an issue with Response.Redirect because it calls Response.End internally which can lead to ASP.NET silently throwing ThreadAbortExceptions. A good thread on this problem can be found here. The same is likely true of Response.RedirectPermanent, so the upshot is you might want to use these lines of code to avoid the exception being thrown although there are more thorough solutions on offer.

Response.RedirectPermanent("http://www.danmaharry.com", false);
HttpContext.Current.ApplicationInstance.CompleteRequest();  

Your mileage may vary with each approach.

Inline HTML Encoded Strings

Script injection is one of those attack vectors on a website which is easily missed if you're not careful and has the potential for a great deal of grief if you do forget. A first guard against this is to HTMLEncode any user input before being stored in the database or shown on screen. Typically this all done in the code-behind, but the latter can now also be achieved inline using the new <%: message %> syntax, which will automatically HTML encode the given message string. For example,

<p>Unencoded : <script type='text/javascript'>alert('hello');</script></p>
<p>Encoded : <%:"<script type='text/javascript'>alert('hello');</script>" %></p> 

The top line will have the browser running the javascript in the script tags. The bottom line will HTMLEncode the script tags and produce the following code (on one line - the line returns are for clarity).

<p>Encoded : 
  &lt;script type=&#39;text/javascript&#39;&gt;alert(&#39;hello&#39;);&lt;/script&gt; 
</p>

Take care not to HTMLEncode a string in code-behind and then also inline with this syntax. ASP.NET will simply HTMLEncode it twice - probably not what you need.

Side note: Two other items of import with respect to ASP.NET security have happened recently.

That's all for today. In the next episode, we'll take a look at Routing for Webforms. Happy coding!