I'm having a strange issue in my production website, which pops up somewhat consistently but with no known pattern.
My app consists of two websites, one of content which lists courses which the user can choose to apply, and the second under https where he actually applies (and pays) for it. I'm using routing in both of them (as per client's decision) and sometimes, when the user navigates from one to the other (a simple href link), upon 'arrival' on the https site, the routing with the course id gets lost and it redirects straight to the default.aspx page, and it crashes. I'm logging errors and I know for a fact that the loss of route (and routedata) is what's causing it (the route should be https://shop.courses.com/ins/{courseid}/ and it's throwing https://shop.courses.com/default.aspx).
In both cases I'm using WebForms, not MVC, and as mentioned, it's not constant. Both sites are hosted internally in a webfarm, running IIS 7.5
Related
On my ASP.NET Site (.Net Framework 4.5) if a user provides a pagename such as http://staging.site.com/index.aspx the site loads as expected and the user can navigate around the entire site without issue.
If the user loads the site and than changes/visits a URL that redirects to the root http://staging.site.com/ with no page name, the first load hangs up for over a minute and than all requests thereafter are also slow.
The issue is only isolated to the users session. It does not affect other users.
Turns out we had enabled session variables to be used in our webapi classes. And the overhead of doing this was causing the server performance to decline significantly
I have a few ASP.NET sites running on one IIS server, of course using different ports. The sites allow for logging in via forms authentication. Session state is stored on a local state server. My problem is that when a user logs into one sites and then navigates to another, they get an exception from the second site and have to close/reopen their web browser to be able to access it. My guess is that the cookie from the first site is making it appear that they're logged in on the second one as well (though I could be completely wrong about this).
I've tried a few things to fix it (which are probably dumb and have nothing to do with the problem, but I'm far from an ASP.NET expert) including:
1) giving the sites different cookie names in Web.config's sessionState tag, and
2) Moving the sites to different app pools, but the problem persists. Any help would be appreciated.
I'd recommend setting up different domains for each site. If this is local, use the host file to route local.site1.com and local.site2.com to the correct place. Obviously you'll have to keep the port. Then you should be setting cookie with a different domain for each site and not causing the confusion.
Many hosting companies let you define which page will be shown to the user if the user goes to a page that does not exist. If you define some .aspx page then it will execute and be shown.
My question is, why not use this for routing. since I can parse the users URL and then do a server.transfer to the page I want. I checked and there is no redirect sent to the client and the http headers are HTTP/1.1 200 OK.
So, is this a good idea for servers that don't have ASP.NET 3.5 SP1 or if you are not using MVC?
Thanks
You "can" do that, but why not just create an HttpModule and handle the routing there? That's how most of the URL rewriting systems work (in actuality, it's also how the MVC routing works since global.asax is just a pre-build HttpModule with a few extras).
The big thing with relying on that kind of server handling you describe is that you really aren't in control of it, and it is a hackish mechanism... by that I mean you are taking a function of the web server that has a specific purpose and design and laying a different meaning and function on top of it... which means you now have no built in handling for an actual 404 error. Plus, the mechanism you are contemplating is harder to adapt to your purpose than just using the other options available to you.
Unless you need something special from routing, you should consider using an existing routing component such as Mod-Rewrite or one of the dozen or so other popular URL rewriters that were built before the MVC routing engine was implemented and work fine in older versions of asp.net. There are also numerous tutorials on using HttpModules, HttpHandlers, and various other techniques to do routing in asp.net webform environments.
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).
I have a large-ish web project which is migrating from classic ASP to ASP.NET (about time), and would like to redirect requests from the old addresses, such as:
/some/path/old-page.asp?foo=bar
to the new addresses:
/other/path/new-page.aspx?qaz=bak
For a fairly long time, there will be classic ASP pages running in parallel with ASP.NET pages, with individual pages being replaced by their ASP.NET versions over time. Where possible, I want to redirect from the old pages to the new ones to keep users from receiving 404 errors, and also to keep the accumulated PageRank on the pages.
My question is, how would you do the redirection logic from the classic ASP to the new templates? The obvious solution is to replace old-page.asp with some simple VBScript that redirects to new-page.aspx, but in the long run I want to get rid of the old .asp files, so I would like to implement the redirection in such a way that they will exist also after the site is completely running in .NET.
One option would be to map the .asp extension to ASP.NET, and implement the redirection as an HttpHandler, but I guess there is no way of making the classic ASP engine run after the request has been passed to ASP.NET.
A couple of years ago, I ran into the very same issue at an eCommerce company where we upgraded their website to .NET. The main issue is that we had no idea how many customers had the old asp pages in their favorites, as well as the issue of SEO. Yes you can map the asp extension to ASP.net, but you lose the ability to run the asp files at all, so that would require that you update ALL asp pages, which may not be feasible.
The best solution I found at the time was to implement an ISAPI redirection filter in IIS. This is an app that is run by IIS BEFORE, the asp or asp.net runtimes. It would make a decision based on the url or any rules you want, whether it should allow the asp files to run or whether they should be redirected, or use url-rewriting to handle the request. It is not always a clean operation, since it runs before your website's request do, and confusion can happen later if other developers don't know it is running. So make sure if you go this route, that your website has plenty of comments or documentation to let developers know there is this thing in IIS running...
There is a good explanation of how to implement this in Code Project. Go here and check it out. http://www.codeproject.com/KB/ISAPI/isapiredirector.aspx
Good Luck!
You should use the "HTTP 301 - Permanently Moved" response code, as this is precisely what it is designed for.
http://en.wikipedia.org/wiki/HTTP_301
An ISAPI redirection filter will work in the sense that, yes, it will redirect visitors to the new URL.
However there are three key problems with the ISAPI redirection strategy.
More code to write/maintain
Bookmarks and search engine entries will never be updated with the new and correct URLs
If foo.asp is transparently redirected to bar.aspx and both are indexed by Google, you'll have two duplicate URLs to the same content in Google. This clogs up search results and is actually against their TOS I believe.