Invasion of the Response Body Snatchers or How I Learned to Stop Worrying and Love IIS

Today I got burned for the second time on this issue. And you know what our former Commander in Chief said about that: "Fool me once, shame on you. Fool me twice - uhh - won't get fooled again."

So in the interest of not getting fooled again. Here's the deal, all laid out in plain English for the future me to read the next time I have this problem, well, in the future.

I have a lovely little RESTful web service (ASP.NET MVC) that has some (IMHO) elegant exception handling built in. The controller action is wrapped in a nice big try-catch and when an exception is thrown the catch block passes the exception to a class that logs the failure and then creates a "Fault" message for the caller (basically an XML representation of the exception details). The response status code is set to 400 - Bad Request and the response body is set to the aforementioned XML "fault".

This code all works fine, that is, until it doesn't. When hitting the service locally everything is fine and the correct XML "fault" message gets returned in the response body, but from a remote client the response body is simply the 11-byte string "Bad Request". Pretty baffling behavior, until you figure out what's going on and understand the rationale behind it. Turns out that this behavior is by design and built into IIS.

At first blush this looks Just like remoteOnly behavior in web.config. The idea there being to prevent gifting sensitive details (like DB connection strings and the like) to potential hackers and foreign spies in the guts of an error response. All well and good. Only I couldn't fix this problem by setting customErrors mode="off". It turns out that this basic functionality is now built into IIS as well, downstream of the handler processing the request. That is, *after* the request has been processed by my code and the response created. It's like IIS sees my 400 and says to itself "Uh oh, trouble in paradise. And look, this is some shifty outsider causing this mess. I better wipe out the response body and replace it with something innocuous. Oooh, I know! How about the text 'Bad Request'? Makes me sound tough! Perfect!"

[N.B. I know, I've broken one of the cardinal rules - "Never anthropomorphize computing equipment" - but I think it's pretty innocent in this case. It's a web server after all. It's not like it's going to take over our nuclear power plants and enslave humanity or anything.]

Anyway, it turns out there's now an httpErrors element in web.config and applicationHost.config that supersedes what's in customErrors. So if you want to display the real response body on anything that has a response code of 400 or greater you now have to set this to allow detailed error messages to be displayed to remote clients (either directly in the file, or via IIS Admin).

(As a side note - I believe this is new to IIS 7.0, I haven't found any historical info on this, but I'm pretty sure that prior to IIS 7.0 things didn't work this way. Either that or I'm getting a little bit senile in my old age. Anyone know which it is?)

Why would you want to override this behavior and make your site vulnerable to terrorists? Remember, you're either against us or with us! Well in my case I was doing integration testing with a new partner deployment on QA server and needed the detailed info troubleshooting. Actually, I can think of several scenarios where you don't want this behavior, but I don't fault MS for making it the default. In fact I definitely think they made the right choice. I just wish someone over there would've picked up the phone and called me. Come on guys, one quick call to let me know about this.

Anyway, here are a couple of links that get into more detail.

• How to Use HTTP Detailed Errors in IIS 7.0


• IIS 7.0 httpErrors


• MSDN Docs on httpErrors configuration element

Or if you just want the guts...

In web.config, comment out customErrors in system.web like so:

<!-- customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
   <error statusCode="403" redirect="NoAccess.htm" />
   <error statusCode="404" redirect="FileNotFound.htm" />
</customErrors -->

and then add to system.webServer the following:

<httpErrors errorMode="Detailed"/>

If anybody is thinking to themselves "Duh. It's always worked this way." Please let me know. I'll accept this assertion with minimal evidence, I just really don't remember ever having this problem prior to IIS 7.

♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it

Enable Tracing in ASP.NET MVC

Not as obvious as I had first thought.

First, in your MVC app's web.config add this (as a child of the root
<configuration> node):

<system.diagnostics>
  <trace>
      <listeners>
          <add name="WebPageTraceListener"
               type="System.Web.WebPageTraceListener, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </listeners>
  </trace>
</system.diagnostics>

Next, turn on tracing. Again in web.config add the following (as a child of the <system.web> node):

<trace enabled="true" localOnly="false" mostRecent="true" pageOutput="false" />

(I won't get into thew details on this element but MSDN has all the info here: http://msdn.microsoft.com/en-us/library/6915t83k.aspx)

Now add some Trace.WriteLine() type calls to your controller action, build and run it.

Then you should be able to go to http://localhost/myapp/Trace.axd (or wherever your app resides) and see the list of recent requests and all their trace details, just like in old-skool ASP.NET web forms apps.

Of course, you could also skip all of the above and just use the built-in Controller.HttpContext.Trace class in ASP.NET MVC. It's already wired up and just basically works, but if you've got a bunch of plumbing built on top of System.Diagnostics.Trace (like NCore's Spy class, for example) then that's not going to do you any good.

PS - Yes, I know it's been a *long* time since my last post, but that's just what happens with a baby around the house. It'll get better when he's old enough for me to pay him to write my blog posts.

♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it

Perpetual Re-Education: LINQ, JQuery, EF and ASP.NET MVC

I recently reconnected with a developer friend and former colleague of mine who asked what new technology I'd been playing with. I promised him I'd send an e-mail with some good links and such. After writing up a quick e-mail summary for him I realized that the guts of it were probably blog-worthy (though not particularly durable given how fast things in evolve these days). Anyway, what follows is my e-mail to him. Let me know if I missed any obvious resources or must have reference materials.

LINQ:
LINQ is a huge part of .NET 3.0, not just some dime-store novelty. LINQ is Microsoft’s (IMHO excellent) attempt at adding a functional programming paradigm to the existing .NET languages. Of course LINQ is a huge topic so if there’s only one aspect of it that you examine in detail I would say that you *must* check out LINQ-to-XML. You’ll never want to do DOM/SAX again. I highly recommend the MSDN primer on this. It’s not as long as it seems and covers everything you need to know to dive in. On top of all that, I think LINQ-to-XML is a great illustration of the underlying concepts of LINQ (and functional programming) and will help you to get your head around LINQ as a general-purpose tool.

Of course there’s also the full LINQ-to-XML documentation on MSDN. (Though I think that MSDN docs are sometimes better as a reference than a tutorial/learning tool.)

For an excellent (and thin) tutorial-like approach to learning LINQ I highly recommend the O’Reilly book “LINQ Pocket Reference” by the Joeseph and Ben Albahari. You’re not going to find a more thoughtful, well-written and concise book on LINQ. It’s actually excerpted from their other O’Reilly book “C# 3.0 in a Nutshell” which is also excellent and refreshingly thin (without leaving glaring omissions or glossing over the important parts). So if you’re looking for a good general book on the full range of C# 3.0 features you can skip the “Pocket Reference” and just get the “Nutshell” book instead. As a huge added benefit, the authors have written an excellent (and free) utility called LINQPad that’s basically a cute little LINQ statement/expression work surface. Actually, it’s a full-on C# scripting environment/”snippet IDE” that you can use in all sorts of clever, non LINQ-specific ways. Google “linqpad” for ideas and examples on how people are using it. I can’t say enough good things about the Albahari brothers’ books and LINQPad. In fact, they have a paid version of LINQPad that adds auto-completion. I love the tool so much and find it so useful that I went and bough the upgrade to show my appreciation (though as an aside, the auto-complete feature is really nice, and well worth the $19).

JQuery:
Not much that I need to say here since I know that you share my JavaScript enmity and have already been looking at JQuery. I’m glad Microsoft is embracing the technology and baking it into everything since it appears we’re stuck with JavaScript for a long time to come in our increasingly AJAX-ified world (don’t get me wrong – I love rich, AJAX-enabled web apps, I just wish we could do it with something other than JavaScript). Anyway, my only recommendation here is the Manning "JQuery in Action" book. This is a solid, straightforward introduction to JQuery without a whole lot of fluff. It’s not a reference by any means (I don’t think that’s the intent with the “… in Action” books) but it will get you ramped up very quickly on the JQuery approach and does a great job of really explaining the fundamentals. I think they’ve now got an “early access” version of the 2nd edition of this.

ADO.NET Entity Framework:
I know you’re already up on this one but I thought I would just throw a couple things out there to look at. First off, I wouldn’t recommend the Manning “Entity Framework in Action” book. I know I just said glowing things about their JQuery book, and it’s only fair for me to point out that it’s still an “early access” (read “unedited draft”) version but even that doesn’t make up for the confused meanderings of the text. There are bits of good stuff in there, but it’s just not worth the price of the book. If my opinion changes substantially with subsequent updates I’ll let you know. [As a complete aside, I really do like the Manning Early Access program. It lets you buy inexpensive, pre-release PDF versions of their books and then get updates as material is added.]

If you haven’t already you should definitely check out Stefan Cruysberghs’ series of blog posts on the EF. He’s got a bunch of really interesting, sophisticated stuff in there that will get you thinking about how to use the EF including querying and extending metadata, LINQ-to-Entities and his .AsHeirarchy() extension method (along with some insights on using LINQPad).

Of course, there’s also Julie Lermans’ blog, though I’m sure you already know about that since you’ve got her book.

I highly recommend the EF Extensions library and corresponding blog by the author. There’s a bunch of really useful stuff in there and the code is rich with EF tricks.

Also, I don’t know if you saw this update on the ADO.NET team blog, but here’s a peek at some of what’s planned for the EF in .NET 4.0.

ASP.NET MVC
Last, but certainly not least, is ASP.NET MVC. This is a huge topic but well worth the time. If you’ve been doing WebForms development for a long time and/or haven’t ever trafficked in the MVC approach then this whole thing can be pretty mind-bending, and hard to even get started with. So instead of throwing a bunch of stuff at you and confusing you even more I’m going to make just one recommendation to get you started. Buy the Wrox book “Professional ASP.NET MVC 1.0” by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie. These are *the* guys for all things ASP.NET at Microsoft and this is hands down the best (and briefest) book on the subject I’ve seen. They do a great job of covering a lot of ground in a small book without missing the important parts. Best of all the first chapter (which is really about 1/3 of the book) is a Scott Guthrie’s NerdDinner tutorial which walks you through the creation of a full ASP.NET MVC app from start to finish. This is probably the best way to get your head around the conceptual underpinnings of MVC *and* will give you plenty of good technical detail as well. I cannot overstate how good this book is (coming from someone who doesn’t buy that many technology books, despite what you might think from reading this e-mail).

♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it