I have setup in the script maps for a site in the IIS metabase a wildcard mapping to ASP.Net for a particular directory within the site.
I have a handler setup in the web.config which should be handling requests for said path and it should never return an actual 404.
I have this configuration in place for another site on the same server which is working perfectly.
For this particular site I am receiving a 404 response for all requests matching the path. I don't know if I have a problem with the script maps or the web.config or the handler itself.
How can I find out where the problem lays so that I can troubleshoot it better?
Is there a concrete way for me to ascertain if the 404 is being returned by ASP.Net or IIS itself?
I am using IIS 6 on Windows Server 2003 with .Net 3.5 SP1.
Inspecting the 404 response showed that it was not coming from IIS since IIS had a default 404 page and this was returning a 0 byte response.
The error was actually in the handler.
Related
I have a fairly detailed problem with which I hope someone can help. Basically, I have a .NET 4.0 website hosted on IIS7 that has some pages that necessitate URL rewriting. In order to implement these features, I have added a method to my global.asax that maps the extension-less URLs to their proper ASPX pages, and then performs a context.RewritePath in order to display the correct page.
Initially, I called this method from application_BeginRequest. However, we have some business necessary logging that occurs when Session_Start is called, and it appears that this logging is not always happening since the implementation of the URL rewriting in application_BeginRequest - Basically, every session gets logged in the DB, and after initial deployment of the URL rewriting, our session logs have dropped by about 20%, with no corresponding errors in the application log. At the same time, our IIS logs seem to be showing a relatively unchanged amount of traffic, so to my eyes, it appears that the sessions are not instantiating properly.
As a workaround for this issue, I moved the URL rewriting from application_BeginRequest to application_AcquireRequestState, so that this code won't fire until after I'm (mostly) sure that the Session has started. This works in my local dev environment and on our staging server (Windows Server 2008 - IIS 7 - .NET 4.5 Framework installed). In the Production environment (Windows Server 2008 - IIS 7 - .NET 4.5 Framework), I get 404 errors when trying to browse to the extension-less URL to be re-written.
I'm completely stumped - I've verified that I'm using the Integrated app pool, my web.config has the "runAllManagedModulesForAllRequests=true" attribute, my IIS features include HTTP redirection and static file compression, but nothing appears to be working. There's a hack that I found for using the Classic app pool, and creating extra script map handlers to handle wildcard URLs with no extensions, but I'm hesitant to put that in place in production.
Any help you can provide would be greatly appreciated. Thank you!
I would concentrate on why there was a 20% drop in session logs. Are you sure there wasn't also a drop in traffic? Are you using redirects for people coming to your site using the old .aspx Urls? Perhaps you received more 404 traffic that would not trigger the Session_Start? Did Google Analytics confirm that traffic maintained normal levels after the UrlRewite was put into place? You could also use IIS Log Parser to filter out static files and query 200 vs 404s from the log files to get a better sense of actual traffic.
I'm creating my first FubuMVC application. I've got a physical folder Demo and a route that should handle the "/demo" url. For some reason, when I try to debug it in Visual Studio, it issues a permanent redirect to "/demo/", and then returns HTTP Error 404.20 - Not Found (No default document). When I route the same action to /demostuff, everything works just fine. I noticed that my application startup scripts are fired on the first request, but it's somehow not routed to Fubu's HttpHandler.
I'm using IIS Express.
I am building an asp.net web application which has been working on local and staging. however, when i deployed to live, there is a little weird issue occurred. below is the live environment details.
live environment:
Server 2003
IIS 6
when the request url is below, if page not found, it will redirect to page 404 configured in the IIS.
"http://www.xxxx.com/folder1/default.aspx"
however, when the request url is below (with a dot in the folder), it will show a IIS default 404 message which is "The system cannot find the file specified." which isn't what i configured in the IIS and it seems like it skips all the http handlers and modules. Therefore, my custom http handler stop working with this kind of url.
"http://www.xxxx.com/folder.1/default.aspx"
My guess it something to do with the IIS setting. i have have several research, there is no other issue like me.
appreciated if anyone can help. Thanks a lot.
Dion
One of the possible reason could be tool such as UrlScan - you need to explicitly configured it to allow dot(.)s in the url - this can be done by editing <Windows Folder>\system32\inetsrv\urlscan.ini and setting AllowDotInPath=1
A vulnerability scanning service regularly tests our site for PCI scan compliance. It has just started trying to access URLs with abnormal formatting, such as:
http://www.mydomain.com/ShoppingCart.aspx//ErrorPage.aspx%3fid%3d2?
We have a Custom Error Page set which works for everything except this. Is there any way to force IIS to display it for this type of URL?
The Error: Runtime Error - An application error occurred on the server....
We're using:
ASP.NET 2.0 (Framework 3.5)
IIS 7.0 (Windows Server Web 2008)
I've tried to debug this, but I can't reproduce this on IIS 6.0.
There might be a more simple solution, but if you're on IIS7 you can use URL Rewrite to match those type of URLs and map them back to your error page.
The %3f part isn't being parsed by IIS 7 and so it can't find the page. If you look in your site logs you'll probably see some 404's.
You'll need to configure IIS 7 to point to your errorpage.aspx file as it's default 404 page.
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).