What scenarios cause IIS to generate a 302 besides response.redirect? I'm working on an legacy ASP.NET app and it's generating 302s in IIS. The thing is, the code doesn't make any response.redirect calls. I don't know how to debug this thing. Could losing session generate a 302? I'm totally lost.
It can happen if you return a CSS file in ASP.NET over http when it should be over https, ive seen that happen in the past. Also if any web services tied into that application that are getting hit or making passes that fail, that could cause it too. Just shooting from my hip and trying to recall the last time I seen those issue's arise.
Check at the IIS level, not ASP.NET level.
Check the IIS management console. Possible options are:
"URL rewrite module"
"HTTP redirect" (under the website settings, for IIS7)
Related
We're moving an instance of a third party, .NET-based website to a Win2016 server, IIS 8, from an external hosting service. Under the site, there's a WCF web service in a subfolder. There are no virtual directories or apps.
mysite.../Order/v4/service.svc
When I browse to pull the wsdl (https://MySite.../Order/v4/Service.svc?wsdl ), it is redirecting to Login.aspx (https://MySite.../Order/v4/Login.aspx).
Browsing to https://MySite/Order/v4/Service.svc?wsdl redirects to https://MySite/Order/v4/Login.aspx .
IIS has no default document set / web.config's defaultDocument is commented out.
Vendor indicates
That would be a redirect that was setup either on IIS or another
appliance that is doing that.
Same behavior occurs running on the server itself (localhost) and sys eng confirms it shouldn't be leaving the network to hit any firewall.
There are no other .config files on the server with any reference to "Login.aspx".
This still feels like it is some piece of configuration but even doing things I shouldn't need to do like restarting the server just to make sure no caching of settings is hanging around isn't affecting it.
Any guesses on what might be attempting to redirect?
Following Rich-Lang's suggestion in comments provided the information to identify that the global.asax file was handling an error in the web.config. Since the code in this case was in codebehind in a dll, and the vendor indicated their code does not redirect, I had not seen that culprit before. Removing the global.asax and turning off customErrors allowed me to see the underlying issue.
I've set up a new Windows 2012 R2 server running IIS 8.5.
We noticed that when an error occurs (eg the ASP.NET State Service was not running) that instead of outputting a 500 status code error screen, the request actually returns a totally blank page (only headers - with no content). We obviously need to see the errors and serving 200 OK for an error could be very problematic for indexers like Google etc or any wesite monitoring tools (which would not notify us that the site had gone offline).
On our other servers (IIS 7) we see the "yellow error screen" with a message like "could not connect to state server" (or similar).
What could possibly be wrong here? Is there some setting to globablly disable all errors (but this would be stupid if it also serves the 200 status code) or could something else be getting in the way?
The only other thing which could be interfering is we've got ISAPI_Rewrite installed on the server (but this doesn't usually cause this problem).
Thanks!
Had a similar issue on Windows 8.
In settings search for "Turn Windows features on or off".
Check that the following features are enabled
"/Internet Information Services/World Wide Web Services/Common HTTP Features/HTTP Errors".
"/Internet Information Services/World Wide Web Services/Common HTTP Features/Static Content".
You need to ensure Server Side Debugging is not enabled in the ASP module.
Classic ASP server 500 errors are returned as 200's. An attempt is made at opening the Server Side Debug Application, that then can't be found and IIS subsequently returns a 200 response and a blank page.
Make sure that you are not calling Server.ClearError() in Application_Error of Global.asax.cs that ended up being my problem.
Ripping out all Global.asax code helped me to find the cause of the error.
After that, the IIS started to return the error page as expected. Then, after the fix is applied, I returned the Global.asax code back.
Maybe this case helps you.
I had a similar issue when requesting the Default.aspx (set as page default in directory). The Server returned status 200, but the Content was blank.
In this case it worked to switch the Application pool's managed pipeline mode from integrated to classic.
Make sure you have enabled HTTP Activation
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 have tried googling and searching for this issue on SO - but have had little success - primarily because I am not sure whether I am searching right.
I am working on an ASP.Net Web Application Project (not website) using Visual Studio 2008, C# and Cassini for testing.
However, everytime I run the site, I get a URL such as:
http://localhost:8671/(S(saifdk55xyhalrqbstrtrdiw))/SubjectClassTeacher/Default.aspx
Even if I modify the URL and try to go to:
http://localhost:8671/SubjectClassTeacher/Default.aspx
I am redirected back to this URL.
The garbage value in the center: (S(saifdk55xyhalrqbstrtrdiw)) keeps changing every few times I compile and I have no idea why it gets injected or how to disable it.
Could anyone throw any light on this issue?
Primarily, I would like to know why this happens and how do I disable this.
Because this happens when I deploy the website on IIS as well.
Any help is appreciated.
Thank you.
This is a clever feature in ASP.NET* called cookieless sessions. It works by injecting your session ID into every URL, so ASP.NET can tell the difference between user A who visits a page, and user B who visits the same page. Normally this is accomplished with cookies, but this approach removes the dependency on the end-user having them enabled.
From MSDN:
...you don't have to change anything in your ASP.NET application to enable cookieless sessions, except the following configuration setting.
<sessionState cookieless="true" />
*The concept is not exclusive to ASP.NET, but it is baked into ASP.NET and - as you've discovered - can be turned on with no particular effort on the part of the developer.
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).