IIS performance tip: Cache in on consistent casing

ASP.NET, Performance By . Updated June 11, 2014

In Spring 2011, at what would sadly become the final installment of Microsoft’s MIX conference, I attended a great talk called 50 Performance Tricks to Make Your HTML5 Web Sites Faster. I was skeptical about the session due to the linkbait title, but Jason Weber from the IE team proceeded to present one of the most comprehensive talks about web performance I’ve seen crammed into a single hour.

Standardize on File Capitalization Convention

A video of the presentation is still available online as I’m writing this. Streaming seems to be broken, but the full video downloads still work fine. Even three years later, it’s still well worth spending a few minutes to watch his presentation if you’re developing for the web and care about performance.

Out of all the points that Jason covered in his talk, the tip at about 21 minutes into the presentation stood out to me the most: Standardize on File Capitalization Convention.
Click here to read the rest of this post »

Canonical URLs in IIS without breaking localhost debugging

ASP.NET, Azure, Visual Studio By . Posted April 30, 2014

It’s important that public-facing websites respond to requests for both domain.tld and www.domain.tld. You can’t control what your users will type into their browsers and you never know which form of your site’s URL people will use in links that they share in email, social media, and links on their own sites. Of course, you want to be sure that your website responds even if they don’t use your preferred version of your URL.

However, it’s nearly as important that all of those requests are redirected to just one address for SEO purposes. This is known as choosing and enforcing a canonical URL. If you don’t enforce a canonical URL and a search engine indexes duplicate copies of your content, you risk diluting the authority that backlinks have given your content and you even risk incurring the dreaded duplicate content penalty. Both will impact how your content fares in search result rankings.

Though rel="canonical" and improvements to search engine algorithms have helped reduce unwarranted penalties related to this mistake, the risk of unnecessarily falling behind in the rankings is too great to ignore.

To solve that problem, many websites running on IIS make use of its built-in rewrite module to enforce a canonical domain name. Unfortunately, the most obvious way to accomplish that ends up causing trouble when you want to work with the site locally.

Click here to read the rest of this post »

The five minute contact form tweak that saves me hours

ASP.NET, Express.js, JavaScript, Node.js By . Updated March 19, 2014

Operating a website used by predominantly non-technical users can be an eye-opening experience when the time comes to support those users. It’s easy to forget how much of the nomenclature and technical understanding that we take for granted is just unintelligible jargon to others. In fact about 10% of people surveyed this year even guessed that HTML was an STD.

A particularly poignant example I dealt with recently was a user telling me they were using “Google” to browse the Internet on their desktop PC. You’d think that probably means they were using Google Chrome as their browser, right? Nope. They were using Internet Explorer with Google’s website set as their home page.

Unfortunately, assisting the most helpless users with technical issues still requires that they communicate details about their platform and browser to you at least semi-accurately. The broader problem is bigger than anyone can solve in a thousand words, but in this post I want to show you one small improvement I’ve made on my public-facing contact forms to help cut down on confusion with this specific aspect of helping non-technical users.
Click here to read the rest of this post »

REST vs. RPC in ASP.NET Web API? Who cares; it does both.

ASP.NET, Web API By . Posted April 25, 2012

It’s probably an understatement to say that ASP.NET Web API has sparked a bit of debate about RESTful design lately.

Web API’s new features like content negotiation, flexible media formatters, and improved JSON formatter are great, but they’ve been presented as features that are tied to the REST paradigm. That may seem troubling if you’re more accustomed to .NET’s RPC endpoints like ASMX, WCF, and even the way ASP.NET MVC controller actions are often used as a makeshift API.

A couple months after the new incarnation of Web API was announced, I’m still seeing a lot of confusion and unhappiness about Web API’s apparent push toward REST. However, what almost everyone has overlooked so far is that Web API supports RPC just as well as REST.

Click here to read the rest of this post »

jQuery, ASP.NET Web API, and Json.NET walk into a bar…

ASP.NET By . Posted March 13, 2012

There’s been some confusing back and forth lately about ASP.NET Web API and JSON. During the time between the last WCF Web API preview and the current ASP.NET Web API beta, it’s clear that effort has gone into smoothing out some of DataContractJsonSerializer’s (DCJS) quirks. However, while things like DateTime and Enum deserialization have been improved, issues have still persisted with Anonymous Types, Dictionaries, and DateTime serialization.

Unfortunately, the underlying cause of those remaining issues was too fundamental to simply spackle over. One of the most frustrating aspects of DCJS is that it’s rooted in WCF’s mindset that all things can be expressed as XML and then translated to other formats. In that world, data like Anonymous Types and simple collections of key/value pairs are uninteresting oddities. So, as long as ASP.NET Web API is saddled with DCJS, it’s at a disadvantage in scenarios requiring more flexible JSON serialization.

Click here to read the rest of this post »

Web API is now part of ASP.NET (and you can get it today)

ASP.NET By . Updated February 17, 2012

One of the hardest parts of being privy to NDA information is keeping my mouth shut about new developments that I wish I could share with you immediately, often for months at a time.

Recent developments around ASP.NET Web API (formerly WCF Web API) are a perfect example of that conundrum. As development on WCF Web API seemingly stagnated on CodePlex, Microsoft had actually rolled the project into ASP.NET itself. The project was in no danger whatsoever, but (frustratingly) I wasn’t able to tell you that.

So, it’s a relief that today’s today’s ASP.NET MVC 4 Beta release has made that news public:

Top Features

  • ASP.NET Web API
  • Refreshed and modernized default project templates
  • New mobile project template
  • Many new features to support mobile apps
  • Recipes to customize code generation
  • Enhanced support for asynchronous methods
Note: It’s not entirely clear, but installing the MVC 4 beta allows you to use Web API in WebForms projects too.

Though Web API isn’t necessarily a gigantic step forward from using MVC’s controllers as a makeshift API for simple scenarios, it’s great that ASP.NET now has common mechanism for creating these endpoints that works the same way on both WebForms and MVC.

I’ve long held out against pressure to move from ASMX to WCF in WebForms projects, because accepting WCF’s complexity primarily only rewarded me with less flexible JSON serialization. By contrast, I’ve begun converting some of my projects from ASMX to Web API, and have been pleased with how easily Web API replaces ASMX.

I believe Microsoft has finally found a good balance between ASMX’s simplicity and WCF’s power with Web API.

Since it was built with jQuery in mind from the very start, I’m finding that Web API is perfect for the sort of work that I usually write about here. It even automatically responses to requests from jQuery with JSON, even if you use simple URL encoded parameters with the request, so adding an endpoint for AJAX interaction in either WebForms or MVC is a breeze now.

I’ll be writing more about actually using Web API here in the future, but I wanted to get this post published right away to help spread the news that Web API isn’t dead.

To learn more about what exactly Web API is and does, have a look at its section in the release notes. To get up and running quickly with some example code, take a look at the new Web API material on the ASP.NET site.

Using CORS to access ASP.NET services across domains

AJAX, ASP.NET, jQuery By . Updated May 9, 2013

Successfully completing a cross-domain request to an ASMX service using CORS

Work on client-side applications long enough and it’s just about inevitable that you’ll eventually want to make an AJAX request that breaches the browser’s XMLHttpRequest security restrictions. Limitations on cross-domain requests are great when they’re preventing malicious sites from malfeasing, but are a thorn in the side when they complicate your legitimate applications.

Traditionally, direct communication across the same-origin boundary required using a rickety (though clever) workaround called JSONP. JSONP is a reasonable compromise if all you need to do is make blind requests to a third-party API like Twitter, but comes up short if you need to use any HTTP verb other than GET. Of course, that’s a deal-breaking issue when you’re working with ASMX ScriptServices or ASPX page methods.

Luckily, a relatively new feature has been making its way into browsers which provides a robust solution to the cross-domain AJAX problem: CORS.

In this post, I’m going to show you how to recognize exactly which requests are cross-origin, how to enable CORS for your ASP.NET site, and the extra configuration necessary when you’re working with ASP.NET’s JSON-enabled services.

Before we get started, I want to emphasize that this approach won’t work with any version of IE prior to IE10. If supporting older versions of IE is a requirement in your target environment, you’re stuck with something like JSONP or a server-side proxy. This will work in any version of IE if Chrome Frame is installed and enabled by your site/server though.

Click here to read the rest of this post »

Help me organize my posts about using jQuery with ASP.NET

ASP.NET, General, jQuery By . Posted November 29, 2011

Image by OZinOH on Flickr

One of the longest running themes here has been the compelling intersection between ASP.NET and jQuery. Beginning with my post about using jQuery to circumvent ASP.NET AJAX’s client-side apparatus for calling ASMX services, I’ve been writing about using ASP.NET and jQuery since the Spring of 2008.

As these related posts have accumulated over the years, I’ve made an effort to weave a thread of cross-links between them posts where appropriate. However, it’s nearly impossible to anticipate every possible entry point and subsequent path that someone might find themselves following here.

So, I’ve decided to finally do what I should have done a year or two ago: Create a top-level index to organize and improve the accessibility of my content for ASP.NET developers interested in integrating jQuery into their sites.

You can see my first draft of that here: jQuery for the ASP.NET Developer

Unlike the other content here, I’m publishing this one long before it’s “finished”. My hope is that I can solicit early feedback to help better construct a useful narrative while the document is still in its formative stages. So, if you have any feedback on the current page or what you think should ultimately be there, please leave me a comment on either this post or that page, contact me directly, or even @mention it my way on Twitter.

ASP.NET page methods are only as secure as you make them

AJAX, ASP.NET, jQuery By . Posted September 8, 2011

One of the most persistent misconceptions about ASP.NET’s page methods is the notion that they have some intrinsic protection against requests that don’t originate from the page where they’re defined. Since a page method’s code resides within a page’s code-behind file, it’s intuitive to assume that those methods benefit from some form of inherent security.

Unfortunately, that is not the case.

Click here to read the rest of this post »

Use ASP.NET’s HttpHandler to bridge the cross-domain gap

AJAX, ASP.NET, jQuery By . Updated August 5, 2011

When you’re developing client-side applications, a problem you’ll almost inevitably have to deal with is how to work with services that reside outside your website’s domain. Though many modern APIs do support JSONP, which is a clever workaround to somewhat mitigate the cross-domain problem, JSONP has its own problems.

Worse, if you encounter an API with no JSONP support, the cross-domain barrier can quickly become a formidable one. CORS is slowly becoming a viable alternative, but it requires that the remote service support it via special HTTP headers and browser support for CORS is still not ubiquitous.

Until CORS is more broadly supported, an alternative solution is to bounce cross-domain requests through the web server that hosts your website. In ASP.NET, the best tool for implementing that sort of middleman endpoint is the HttpHandler.

In this post, I’ll show you how to create an HttpHandler to service cross-domain requests, how to use jQuery to communicate with the handler, and an example of one improvement that this approach makes possible.

Click here to read the rest of this post »

s