A Blog for Graymad

For those who may not have noticed, in the frenzy to prepare for Thanksgiving here in the States, Dino Esposito, one of the foremost authors on all things ASP.NET (and a fellow MS Press author to boot!), has joined .NET Weblogs. Welcome, Dino, and subscribed!

My son, my wife, and I have all come down with a stomach virus over the last week. Fortunately, my son's case was mild. My wife's ended up with a trip to the emergency room, a sonogram, and a CAT scan (fortunately the results were good...if, by good, you mean "just a virus that has you miserable for days"). My own case had me bed-ridden for the better part of 2 days, and still wishing that I was in bed now. The only reason I'm up and about is that we have family coming in tomorrow for the Thanksgiving holiday, and there's just too much to do to let stuff go any longer. So if I'm a little slower than usual in answering email, or other communications...now you know why.

My thanks to Stephen Swienton, Greg Kane, Cory Smith, Todd Raymond, and all of the attendees from the Fort Worth .NET Users Group.

I had a great time talking with the group about the new features in ASP.NET Whidbey, and got lots of great questions from the group. I also gave away copies of several of my books (something I try to do at every user group I speak to), and spent a little time chatting with several attendees after the event. I know Stephen from several online organizations including ASPInsiders, and had met him on several occasions in person, but had not yet met the other officers of the group (though I knew a couple of them from online interactions as well). Greg works for Justin Brands, maker of a number of lines of boots, including Tony Lama. The meeting was held in Justin Brands' office in Fort Worth, and I have to say, it was kind of cool having a user group meeting in a building that smells like leather. ;-)

Thanks, too, to INETA, for sponsoring the event.

I've written a number of ASP and ASP.NET books over the last 5 years, and one of the challenges, particularly with .NET and ASP.NET, is deciding what gets covered, and what doesn't. With ASP.NET Whidbey, this challenge gets even harder, because of all of the new features that have been added. So I'd like to get some feedback on what the community thinks should be covered in a book on ASP.NET Whidbey. Would you like to see:

• A smaller book that covers just new new features in Whidbey, with the features of 1.0 and/or 1.1 being covered by existing books remaining in print longer.
• A smaller book that covers just new new features in Whidbey, with the features of 1.0 and/or 1.1 being covered by supplemental materials on CD-Rom and/or online.
• A large book that covers all of the features, both those that exist in the current frameworks, as well as those in the new version, keeping in mind that such a book would likely cost more, due to the additional costs of publishing a larger book.
• Something else?

eWeek, in an article posted yesterday, noted some pretty discouraging reliability numbers for enterprise Java applications, with survey results indicating an average uptime of just 88%. The article also raises questions about performance and meeting user expectations.

Now, in all fairness to Java, I'm willing to bet that, as indicated by the article, at least some of the deficiencies reported have more to do with poor application design/development than with any inherent deficiency in Java itself, but it does point out that even with a tool that is widely touted by some folks as being superior to .NET, enterprises have some trouble getting good reliability and performance. Regardless of the whether you're talking about problems with the environment, or with application code, I think it's less about which tool you use, than whether your application design and execution is up to snuff.

Just a quick reminder to those in the Dallas/Ft. Worth area (the rest of you can go about your business) that I'll be speaking at tomorrow night's Fort Worth .NET User Group meeting, about what's new in the upcoming version of ASP.NET, codename Whidbey. There are a lot of neat new features to talk about, so I hope to see lots of folks there. Meeting time is 6pm.

• Bad News: Longhorn doesn't appear to like my video card (or at least the XP drivers), and either automatically reboots or blue screens when rebooting after installing the drivers.
• Good news: The Last Known Good Configuration setting works, and got me back into Longhorn, with the video card set to use the generic drivers.
• Even better news: The good performance I was crowing about in my previous post was without any hardware acceleration!
• Bad news: I suspect my chances of finding Longhorn-compatible drivers for this card are slim to none.

OK, so I probably should've just gone to bed, but I figured what the heck, and went ahead and installed the Longhorn PDC preview on my new Dell PowerEdge 400sc. What a difference proper hardware makes! Not only did the install go much faster than when installing in a VM (no big surprise there, other than the extent of the improvement), the hardware detection phase only took a little longer than the 10 minutes it claimed (as opposed to the couple of hours reported by some). The install was certainly both easier and faster than any other version of Windows I've installed (including the Windows Server 2003 install I did last night).

When the install was complete, Longhorn had automatically detected and installed drivers for every piece of hardware on the machine, with the exception of the video card and the sound card. Once I pointed the New Hardware Wizard at the correct (XP) drivers, both installed without a hitch. I'm liking this so far...

The best part is that the performance on this box is a pleasant surprise. Sure, there's the occasional drawing hiccup when I auto-hide the sidebar, but the zooming of the clock and/or icons in Windows Explorer is very smooth and not at all laggy. Definitely goes to show you that if you give Longhorn some video RAM to play with, it runs pretty well, even in alpha. Nice work, folks!

Next up is installing Whidbey and the Longhorn SDK...but I think I'll let that wait until tomorrow.

Got the machine that I ordered for my longhorn, etc. experiments. I actually got it on Friday, but my wife told me in no uncertain terms that I needed to finish my latest article for the MSDN ASP.NET Developer Center before I opened the box. She was right, of course, as I proceeded to (as soon as the article was done and wending its way to Kent) stay up until 5am getting the server (mostly) set up.

In addition to the stock setup that I ordered, I added 1GB of 400mhz DDR RAM, an inexpensive Radeon 9200se knock-off (8x AGP, 128MB video RAM), and a 4X DVD+R/RW drive. I didn't have a chance to install the software for DVD playing/burning until today, but the only problem I ran into was that the freebie version of Roxio's Easy CD Creator (with DVD) stinks, big time. It's an old version, of course, and although I was able to get it to recognize my drive after downloading the latest patches, it locked up at the very end of the burning process, and required a reboot to unlock the drive. So I downloaded a demo copy of Nero, which seems to do the job much better. Perhaps worth the $70, if it'll save me from destroying disks left and right (and pulling my hair out).

The really excellent news is that I'm able to confirm that all of the 800mhz bus versions of the 400sc use Hyperthreaded processors. Since the first OS I installed was Windows Server 2003 (I haven't gotten around to installing Longhorn yet, probably tomorrow), I didn't need to do a thing to enable hyperthreading. So far, the box seems very zippy. We'll see how the performance is with Longhorn.

To make a long story short, whether you're looking for a machine to play with Longhorn on, or just an inexpensive server or workstation machine, I would certainly recommend that you take a look at the Dell 400sc. It's inexpensive, the performance so far seems very good, and the build quality and attention to detail are really impressive. The chassis is nearly completely toolless (the only exception being that you need a screwdriver to attach the drive rails if you're installing a new drive), and is set up to make upgrades almost entirely painless. To upgrade the video card I simply opened the case, released the latch holding in all the expansion cards, removed the crappy 8MB PCI card, installed the new AGP card (note that AGP is functional, but not officially supported), and replaced the latch. All of the drive cable plugs have loop handles so that you can remove the plugs without straining the cable or bending pins...very well-thought out. As if you can't tell, I'm very pleased with this machine (I'm already considering buying another to replace a noisy rack server I use for my Web server...unlike my noisy box, the 400sc is nearly silent).

UPDATE: If you're running Longhorn on hardware (as opposed to in a VM), I'd be very interested in hearing what kind of video card you're running and whether you have hardware acceleration working properly with the card. If I can find out about a card that's verified to work with Longhorn without crashing it, I may bite the bullet and pick up a new card to see what difference hardware acceleration makes.

I've long been a big proponent of the new Request Validation feature of ASP.NET v1.1 as a first level of defense against cross-site scripting attacks on your web applications, and have advocated leaving this feature enabled (it's on by default) unless you explicitly provide filtering and/or HTML encoding of all input to your application.

Well, a flaw has been reported in the implementation of this feature, such that it can be bypassed by specially malformed tags. The report was brought to my attention by a post from Kirk Allen Evans, who saw it on a Developmentor list. Since I've been a vocal advocate of the use of this feature, I thought it important to note the flaw.

One of the things that this highlights is that RequestValidation should only be considered (as I mention above) a first line of defense, not a complete security solution. As Scott Guthrie and others have consistently recommended, you should always HTML encode any and all text input that you accept from users that will (or may) be stored and/or displayed later. You should also consider using regular expressions (in conjunction with the RegularExpressionValidator control) to limit input to solely those characters or character sequences that are appropriate for any given input field. Taking such a multilevel approach to processing input can help protect you from a flaw in any single input filtering technique.

A fix for this flaw is available, and was made available as part of the ASP.NET 1.1 June 2003 Hotfix Rollup Package. Unfortunately, it appears that that rollup can only be obtained by contacting Product Support Services. However, a later rollup that also includes this fix can be downloaded from Microsoft. Note that hotfixes generally have not undergone the same level of testing as official patches, so if you are not directly affected by this (if your applications do not accept input, or if you've already got input filtering in place), you may want to wait for the next service pack for the .NET Framework, which will include this fix.

Bottom line is that although a fix is available for this flaw, you should always treat input appropriately, regardless of any built-in features. This means always providing your own filtering and/or (preferably and) encoding of input your application accepts.