Geeky Bob

My good friend Wade Hilmo recently posted an excellent blog titled "How IIS blocks characters in URLs" that discusses some of the internal workings for how IIS deals with several characters in file names that do not work well in URLs. Wade’s blog does a great job explaining all of the internal IIS URL parsing logic in detail, and his post reminded me of some related notes that I had published on an internal website at Microsoft. As a complement to Wade’s outstanding blog post, I’m reposting my notes in this blog.

Recently a Microsoft Technical Account Manager (TAM) mentioned that he was working on an issue with a customer that was using SharePoint 2007 on IIS 7. The customer's problem was this: his company had several Word documents that were stored in SharePoint that had the plus sign (+) in the filenames, and HTTP requests for these documents were failing. The TAM configured IIS 7's request filtering feature to allow doubly-escaped characters by setting the allowDoubleEscaping attribute to true. This seemed to alleviate the problem, but I had to point out that this probably wasn't the right thing to do. As a general rule, I don't like changing many of the default configuration options for the IIS 7 request filtering feature, because they are designed to keep my servers safe. But in this specific scenario, modifying those settings is simply looking in the wrong place.

Let me explain:

There are several characters that are perfectly valid in a Windows filename that are really bad when you post those files on websites, and either the server or the client could wreak havoc with them. In most scenarios the HTTP requests will receive an HTTP 404 File Not Found error, but in some cases that might cause an HTTP 400 Bad Request error. As such, even though you might find a way to work around the problem, it's a really bad idea to use those characters when you are posting files to a website.

RFC 2396 is the governing document for "Uniform Resource Identifiers (URI): Generic Syntax." This RFC defines what can and can't be used in a URI, as well as what shouldn't be used.

First, section "2.2. Reserved Characters" contains the following list of reserved characters:

reserved = ";" | "/" | "?" | ":" | "@" |
           "&" | "=" | "+" | "$" | ","

Second, section "2.4.3. Excluded US-ASCII Characters" contains the following lists of delimiter and unwise characters:

delims = "<" | ">" | "#" | "%" | <">

unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

Several of the characters in those lists cannot be used in Windows filenames, but the remaining characters should not be used for filenames if you intend to upload those files to a website.

Here are my explanations for why some of those characters will cause problems if you attempt to use them in filenames that you upload to a website:

• Plus Sign (+) - this character is often translated as a URI-encoded space, so the URI "http://localhost/foo+bar.doc" could be misinterpreted as the URI "http://localhost/foo bar.doc".
• Percent Sign (%) - this character is used for URI escaping, and I've seen this cause a lot of problems because the two characters that follow the percent sign are assumed to be hex digits for an escaped ASCII code, so the URI "http://localhost/foo%bar.doc" could be misinterpreted as the URI "http://localhost/fooºr.doc".
• Number/Pound Sign (#) - this character is used to delimit a URI from a fragment identifier (aka bookmarks), so the URI "http://localhost/foo#bar.doc" could be misinterpreted as the URI "http://localhost/foo" with a bookmark of "bar.doc".

So once again, just because you might be able to get this to work on your server doesn't mean that you should be using a character in a web-based filename that's reserved for something else. It's like building an atomic bomb - just because you can doesn't mean that you should. Your best answer in this scenario is to rename your files to something else.

;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

Following on the heels of Clive Webster's article that FTP is 40 years old, let me be the next person to wish FTP a wonderful 40th birthday!

Happy Birthday FTP!

Yeah, that was kind of silly, wasn't it...? ;-]

I'm a little slow on this bit of news, but I just stumbled across the Goodbye from Seattle: Microsoft ending Zune device article from a month ago on GeekWire. This was really bad news for me - I own several Zune devices, so I would be extremely sad to see them go; personally I think that Zunes are great media devices that have a lot of potential. Given the existence of a large body of anti-Apple users, which has led to the creation of websites like anythingbutipod.com, there are a lot of people that don't want to settle for an iPod.

As I was lamenting the untimely demise of my favorite media player, I came across the Zune Is Not Dead article on anythingbutipod.com, which was published the day after the GeekWire article was published. The anythingbutipod.com article contained a statement from Dave McLauchlan, who is the Senior Business Development Manager for Zune, and he stated rather emphatically that the Zune is not dead.

So this leaves me a bit confused, at least for the moment; I'm not sure what to think about the future for Zune devices.

FWIW - I have two Zunes, a Zune 120 (black) and a Zune 30 (red), both of which have been great devices for me. I use my Zune 30 every day during my commute to listen to audiobooks, and I use my Zune 120 when I'm traveling in order to listen to music and watch movies.

In addition to my Zunes, my wife, my son, and my daughter all use a Zune. (I also own an HTC HD7 that is running Zune on Windows Phone 7, but that's another story.)

All that being said, the Zune never reached a critical mass, and I could easily make a wish list of features that I think would help the Zune in the long run. Here are just a couple:

• Transferring files to and from a Zune should not require using the Zune software.
  This is an annoying limitation, and I realize that it's the same model that is used by the iPod with iTunes. But Microsoft already makes Windows Media Player, and you can use that to transfer files to/from third-party players, so I find it somewhat limiting that you have to use the Zune software.
• The Zune should show up as a removable device in Windows Explorer like most third-party media players.
  This is somewhat related to the previous comment, but here's an example: my dad and my aunt both own media players from Creative, and it's great that their media players show up as removable devices in Windows Explorer when you plug them in. There's an old adage that says, "You can't teach an old dog new tricks," and it's great when you don't need to try. My dad is in his early 70's and my aunt is in her early 80's, so it's great that they can stick with the simple drag & drop or copy & paste functionality in Windows when they want to update the media on their players. (For that matter, I wrote a batch file that my dad uses when he adds MP3 files to his media player that automatically updates the metadata; all he has to do is run the batch file when he adds new files to his media player and everything is up-to-date. You can't do that on an iPod or a Zune.)

Anyway, that's my $.02 on the subject. I love my Zunes, and I hope that Microsoft decides to keep them around.

I've seen a few situations where people that are using the FTP 7.0 and FTP 7.5 service have noticed that it takes a while for their password changes to be reflected by the FTP service. To put this another way, here are the typical symptoms that people describe to me:

• A user successfully logs into their FTP site using their username and password
• The user logs out of their FTP site
• The user changes their password
• The user attempts to log into their FTP site using their username and their new password, but this fails
• The user can successfully log into their FTP site using their username and their old password
• (Note: As a corollary, restarting the FTP service fixes the symptoms)

Here's why this happens: to help improve the performance for authentication requests, the FTP service caches the credentials for successful logins. (The cache duration is set to 15 minutes by default.) This means that if you change your password, your changes may not be reflected for the cache duration.

The good news is, the FTP credential cache settings can be changed easily, and I have documented all of the settings for FTP caching in the IIS configuration reference at the following URLs:

• FTP Caching <caching>
  http://www.iis.net/ConfigReference/system.ftpServer/caching
• FTP Credentials Cache <credentialsCache>
  http://www.iis.net/ConfigReference/system.ftpServer/caching/credentialsCache

Quoting and paraphrasing the above documentation, there are the two settings that you can configure on the <credentialsCache> element:

What this means to you is - you can completely disable credential caching, or you can specify a different timeout. For example, on several of my development servers I often disable credential caching; this allows me to change passwords whenever I want, which is very useful when I am creating custom authentication providers. For my production servers I tend to stick with the default values, although I might change those values when I'm troubleshooting a problem.

I usually configure the settings from a command line or a batch file, although the articles that I listed earlier have steps for using the IIS Manager to change the settings for FTP credential caching. Just the same, here are some examples for setting the values by using appcmd.exe:

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"False" /commit:apphost
net stop FTPSVC
net start FTPSVC

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"True" /commit:apphost
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.flushInterval:"300" /commit:apphost
net stop FTPSVC
net start FTPSVC

I hope this helps. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/