ApplicationPath and the IIS metabase
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.



Pingback: optionsScalper