I've found an issue with ASP.NET that I know at least has stumped one other person out there. We were trying to use an HttpModule to handle wildcard requests to a web application. The generated url is dynamic and could potentially be several hundred characters long. Unfortunately there appears to be a limitation in the aspnet_isapi.dll file that limits the length of the path in the url to MAX_PATH which is hardcoded at 260 chars.
Has anyone else ran into this and found a way around this limit? Query string parameters are not an option.
Thanks, Greg Ballard
The problem actually lies within Windows, not ASP.NET. Windows has set MAX_PATH at 260 and when IIS takes a request for a longer filename, it will fail. You've probably found is this KBase article already, but for anyone else: http://support.microsoft.com/kb/q177665/. The Applies To: Section shows this is expected behavior from NT 3.51 all the way to Vista and Server 2003.
As for a workaround, I had a similar situation, but we would up abandoning our attempts to avoid a query string parameter and did it anyway.
Thanks for your answer. While I didn't find that exact article, I had found similar. However, this is not a limitation in IIS. You can pass a longer path in the request to IIS and it will return the correct response. You can verify by trying with a simple html page. The problem only occurs when using aspnet_isapi.dll to handle requests. Even the integrated debug server within visual studio can handle longer paths than 260.
I ended up using the following in the web.config to solve this problem using Mvc2 and .Net Framework 4.0
@Haacked:
Phil, you mention that this is an issue with aspnet_isapi.dll. Doesn't this mean that this issue should not exist in the IIS7 integrated pipeline mode?
From what I have heard, however, (http://forums.iis.net/t/1105360.aspx) it still does.
I am running into the same problem, and am feeling kind of hooped. It seems that ASP.NET routing is affected. So, any ASP.NET MVC application has to have URLs shorter that 260, after which it has to revert to querystrings, which seems like a complete 180!
(Sorry for answer-commenting... not enough rep to comment yet :( )
You could use an URL-rewriting ISAPI such as IIRF to rewrite the URL into something the aspnet_isapi can process.
This is a known issue with aspnet_isapi.dll and there is currently no workaround. The reason you don't see this issue when running your site in the built-in Visual Studio Webserver (aka Cassini) is because it's all managed code and doesn't rely on aspnet_isapi.dll.
This will get addressed in a future version of ASP.NET.