Lazycoder

2Feb/062

ApplicationPath and the IIS metabase

Web Application Articles

Tip Some testing with Internet Explorer and the Mozilla browser suggests that the path is case sensitive. Ordinarily, URLs on Windows servers are not case sensitive, but this appears to be an exception. You can’t control how users type URLs into their browsers, but if your application depends on cookies tied to a specific path, be sure that the URLs in any hyperlinks you create match the case of the Path property value.

I’ve been pulling my hair out for most of today, which given my age and hairline is not a smart thing to be doing, tracking down a cookie path bug. I was setting the path of a cookie server side, but the browser wasn’t sending the cookie back to the server. I could find the cookie in my browsers cookie collection and if I set the cookie + path manually using Javascript the cookie would get sent back. I knew the problem was somewhere in the HttpCookie.Path property but I couldn’t see anything obvious. So I set the cookie + path using Javascript again and looked at it side by side with the cookie being set server side, they were identical EXCEPT for the path.

server-set cookie: path=/Caisisv3_0
client-set cookie: path=/CaisisV3_0

The only difference was the uppercase ‘V’. I looked at my URL and low and behold it had an uppercase ‘V’ in it. The odd thing is how I was setting the path server side.

diseaseView.Path = Request.ApplicationPath;

I was pulling the path directly from Request.ApplicationPath. When I looked in the IIS admin at the path for the virtual directory, guess what I found? It had a lowercase ‘v’. But, when I hit F5 in Visual Studio and it launched the site in a browser window, the path had an uppercase ‘V’ in ‘CaisisV3_0′. What gives? The only conclusion I can draw right now is that Request.ApplicationPath pulls the name from the IIS metabase. When I look at my .sln file, I see that my web project refrence has an uppercase ‘V’ in ‘CaisisV3_0′. But the ‘v’ is lowercase in my .webinfo file. So when the web site is launched in debugger, it pulls the URL from the .sln file, but at runtime it pulls the Request.ApplicationPath directly from IIS.

Since we have to limit this cookie to the application path, I guess we’ll have to re-create the virtual directories in our NLB cluster and make sure they are all cased correctly. This is a weird friggin’ bug. BTW, this is under IIS 5.1, I haven’t checked to see if the same behavior exists under IIS 6.0.

Share and Enjoy:
  • del.icio.us
  • DotNetKicks
  • DZone
  • Reddit
  • Digg
  • StumbleUpon
  • LinkedIn
  • Facebook
  • FriendFeed
  • HackerNews
  • Netvibes
  • Posterous
  • Tumblr
  • Twitter
Filed under: .NET Leave a comment
Comments (2) Trackbacks (1)
  1. This would be a tricky unit test to write, but I think it could be done. I’d use the following technique (http://haacked.com/archive/2005/06/11/4617.aspx) to control the application path.

    Although, you might want to use Cassini as well as a unit test to simulate the browser and manage cookies (I’ve done this). This would give you enough control to simulate the different casing on application path and how cookies are handled.

    But really, this probably falls under the paradigm of integration testing and might be better served using an automated web testing tool like Watir or them Mercury testing tools.

  2. What can be done for an ASP site?


Leave a comment