What would cause IIS to return a 404, only sometimes? If I hit a 404 on a page, I can simply hit refresh and it will come up. It's reproducible. I've used fiddler to see what's going on and I don't see anything off. I've setup IIS tracing but again, I don't see what exactly the issue would be, the file exists and the 404 only occurs sometimes. By sometimes I mean if I navigated to a page and got a 404 I could refresh and it would come up but other times I could navigate to that page and it would not 404. It isn't limited to any one page or condition.
What other things can I try to determine what the issue is?
If you've run Fiddler and you see the request arrive at the server and you see a 404, then this doesn't sound like a web farm problem.
You might want to try SysInternals ProcMon to see what's going on underneath.
The usual reason for this is that you have a web farm with several machines, on one machine the pages are missing.
Therefore, each time you randomly use the machine with the missing pages you get a 404.
I've had this similar issue and I traced it back to changing this:
<modules runAllManagedModulesForAllRequests="true" />
to:
<modules runAllManagedModulesForAllRequests="false" />
Obviously, analysis will need to be done to make sure that this doesn't affect your application in any other way.
I have only has this when an MVC application because for certain situations my routes were not correct. Clicking would produce the 404 but F5(refresh) would show the webpage correctly. You don't mention mvc but thought it worth throwing this in.
Related
I'm running IIS10 in my dev server but only IIS8.5 on my production server. I'm just pointing out - nothing to do with the issue I have.
I'm using C#/web forms with url routing and am looking to move some httpredirects into my web.config file.
Having looked at the documentation, I have configured it like this:
<httpRedirect enabled="true" httpResponseStatus="Permanent" exactDestination="true">
<add wildcard="/red-widget2" destination="/widgets/red-widget" />
</httpRedirect>
Given that I've used exact destination, I expected just that, but it's not what I'm currently getting.
If I enter a url like this:
https://example.com/red-widget2
I expect a destination like this:
https://example.com/widgets/red-widget
But I actually get this:
https://example.com/widgets/red-widget/red-widget2
I've tried all the attributes to no avail, so how do I correctly configure this redirect?
Here's the answer for anyone else that falls into this trap.
The code I posted above works - it's just that IIS/Chrome doesn't want me to know.
I exited IIS, shut down the project, restarted VS, but still was left with the same issue.
However, when I cleared my browser cache and tried again, I got the answer I needed. What happened was, while I was testing, either IIS or the browser decided they were gonna keep hold of the wrong redirects and keep presenting them back to me, no matter what I changed.
So there it is - if you don't get it right first time, clear your browser cache.
I have just started a MVC project and I faced with a very strange behavior.
When I run it it displays me some empty Home/Index
But when I go to firebug I see tens of very strange and endless requests, like this one:
GET http:// localhost :58567/3a5679dd22ba46d1993...%00101+Firefox%2F33.0&tid=7&_=1417193472430
And such the requests go one after another one and don't stop, although I don't trigger any action.
I don't understand where they come from. My app does not send any request and previously I've never faced with such the behavior. In my previous experience firebug showed me only the requests I made.
Please advise.
These requests come from the "Browser Link" feature in Visual Studio, they're not something you'll have manually added. There's more detail on the feature at http://www.asp.net/visual-studio/overview/2013/using-browser-link , including how to disable it if you don't need it.
I think I may have found a problem with ASP.NET MVC and it's event pipeline. In particular, I am finding that Session_Start is being called multiple times, each containing a new SessionID.
Here's the step-by-step process:
Open VS2010
File | New Project
ASP.NET MVC 3 Web Application, accept default name, click OK
Select Internet Application (although I don't think it matters really), click OK
When finished creating, edit the Global.asax.cs file
Add the following method (yes it's empty):
protected void Session_Start()
{
}
Set a breakpoint in the method
Debug
Notice that the breakpoint is caught twice before displaying the page. If you watch "Session.SessionID" when the breakpoints are caught, you will see that the session id is new each time.
Once you get to the home page, click on the "Home" or "About" tab link.
Session_Start will be fired again, this time with a new SessionID.
Continue execution, and any subsequent actions will no longer fire Session_Start.
I tried the same thing on a standard ASP.NET Web Application (not MVC), and Session_Start only fired once.
I'm pretty sure I'm not doing something wrong here, as I am using the default project templates, and the only code that is being modified is the Global.asax.cs file, to add the Session_Start method.
I am using IIS Express, but I've repeated the above steps using the "Cassini" web server (Visual Studio Development Server), with the same result.
Any advice?
UPDATE
I decided to use Fiddler to inspect the HTTP traffic during my debug session. It seems that:
The first Session_Start is fired when I am requesting the "/" URL. This seems reasonable. The SessionID generated at that time is then written in the response to the browser. Again, seems reasonable.
Fiddler then shows requests/responses for the *.js and *.css files. All successes. None of those fire off Session_Start. Good so far.
Then Fiddler shows that a request has been made for "/favicon.ico". At this time, Session_Start fires, and generates a new SessionID... I continue.
On Fiddler, it shows that the "/favicon.ico" file was not found (404). The webpage is displayed. I click on the "Home" link.
The URL "/" is requested and response is OK in Fiddler. But then, another "/favicon.ico" file is requested, and again Session_Start fires with a new SessionID... I continue.
All subsequent requests have responses, and the browser stops asking for "/favicon.ico".
I made note of each of the three SessionID's generated, and it seems the one that the browser holds on to is the first one. So when we get to step 6 above, and everything seems to work, it's actually using the very first SessionID that was generated.
So... I decided to host a "favicon.ico" file. I placed the ico file in the root of the project, and started my debug session again. This time, Session_Start only fires once. "/favicon.ico" was served successfully (200).
So... I guess it is working the way it should in a sense... But why do calls to "/favicon.ico" fire off the Session_Start event???? Shouldn't I have the choice to NOT host a favicon?
ASIDE: I tried all the above in an ASP.NET (not mvc) project, and it did not have the same problem, even though there was no favicon.ico file hosted by a default "ASP.NET Web Application" project.
I kinda had this problem for a while, and finally I realised that it was because there was some http/https shenanigans going on... looks like it destroys and recreates your session if you flip the ssl around like that and you have
<sessionState mode="InProc" sqlCommandTimeout="3600" timeout="120" cookieless="false" />
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Possibly a trap for new players or people who are really tired and not paying attention! :)
Just FYI in case this helps anyone...
I think I've come to a point where I have a couple of solutions (albeit both seem 'hacky' to me), so I think I'll accept these and move on.
Got a comment from #Tz_ above that mentioned I should ignore the route for the favicon file. That's essentially what I'll be doing. (kudos #Tz_!)
Came across the following post, (among others). It describes a problem that when the browser requests a "/favicon.ico" file from an ASP.NET MVC site, the MVC stack is mistakingly trying to look for and instantiate a controller. I'm wasn't sure if that was true or not for my situation, but the answer suggested adding the following route entry:
routes.IgnoreRoute("favicon.ico");
I gave it a shot (added the above), and that fixed it!
So, I still don't know why "/favicon.ico" request has a mistaken identity in MVC, but I know how to fix it in my situation. Either:
Host a favicon,
or add an ignore route entry.
Again, both seem like hacks to me, as I think this is something controller factories should be capable of handling gracefully. IMHO
Reason you are getting Session_Start firing each time is because you have <httpCookies requireSSL="true" /> in <system.web> in your Web.Config remove this and you are good to go.
I can't reproduce this problem. I've tested on ASP.NET MVC 3/Tool Update, Win08/R2/SP1 and Win7/SP1 using IIS 7.5, Cassini and IIS Express. I see the 404 favicon request in Fiddler, but the break point is not hit for favicon. I tested with IE9, the current FF and Chrome. Each time I hit the site with a new browser, Session_Start() is called and I see the new session ID. I work for Microsoft so I'd like to know how to reproduce this problem.
This happened to me when I had some <img> in my pages with a wrong "src" attribute. Putting a valid path in "src" solved my problem.
we were all recently alerted by scottgu with this security vulnerability. http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
I'm wondering, since I've been redirecting errors via Global.asax on the Application_Error event, I was wondering if that can suffice the fix for this issue or do I still need to place a setting on the web.config?
The problem is that (according MS) you need to respond ALWAYS in the same way, no matter the specific error you have.
You'd need to redirect the user to the same page on errors 404 and 500. That's why the easiest way would be using the web.config setting.
They say that this would be temporary and you could revert it once they release a patch for this.
This is the Scott answer to a similar question:
I would recommend temporarily updating the module to always redirect to the search page. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.
Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now I'd recommend not differentiating between 404s and 500s to clients.
We run a link redirection service which can handle links thrown at it in various formats. One of these formats is to append the destination URL to the end of the link, for example
http://url.fwd/abcd/http://www.mydomain.com/page.aspx
This was working on a Windows Server 2003 / IIS6 box for the last two years, but now we're trying to move to a Windows Server 2008 / IIS7 setup and its not working anymore.
I've read about the problem with colons in the URL but it doesn't affect pages not ending in '.aspx'. For instance,
http://url.fwd/abcd/http://www.mydomain.com/page.php
would redirect fine.
http://url.fwd/abcd/http//www.mydomain.com/page.aspx
also works fine (note the lack of a second colon). Despite being the wrong URL, it does get handled by our URL forwarding system, which uses a custom 404 page. On the old system, we had a similar problem, so a method was written in Global.asax > Application_Error specifically to handle the '.aspx' case, and it worked fine.
On our new server, the Application_Error never gets thrown in Global.asax. Instead, I get a System.NotSupportedException - "The given path's format is not supported". This System.NotSupportedException is the exact case we handle in the Global.asax page, so it's definitely not being fired.
I've changed the registry keys indicated in several forum posts,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET VerificationCompatibility=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP|Parameters AllowRestrictedChars=1
I've tried changing the Handler Mappings settings for .aspx.
I've tried setting the App pool to use classic mode instead of integrated, but this causes a completely different error where static content such as images and CSS do not display at all. I've checked that static content is enabled in the windows features, and it is.
Under classic mode, the '.aspx' request throws two Bad Request errors with absolutely no information whatsoever. The code of the error page I get is literally
Bad Request<html><body>Bad Request</body></html>
UPDATE: I've changed the static file Handler Mapping to the form found in this page
http://improve.dk/blog/2006/12/11/making-url-rewriting-on-iis7-work-like-iis6
However, as the author rightly points out, this is a hack and not the correct way of doing things under IIS7. It also only fixes the static file problem in classic mode. '.aspx' pages still throw an error under classic mode.
Any thoughts or input would be greatly appreciated at this point.
IIS 7 Solution
The easy solution in IIS 7 is to add a setting in your web.config file to tell IIS to process all requests through your Global.asax events. Just add or change this section in your web.config to enable requests:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
In my case, I was publish my site in production and I miss copy to server App_global.asax.compiled file. For this reason was not fire the Events inside Global.asax.
Hope anyelse help this tips, I lost 8 hours seeking.