I've recently upgraded a page on our server from classic asp to asp.net
The page recieves postdata and saves it to a file. The page is used by many of our clients and the url (to the asp page) is hard coded into their software. This means that i cannot simply swap the old page out for the new one.
I'm trying to find a way to redirect clients from the old url to the new one.
I know you can do a simple redirect using IIS, but this does not cause the postdata to be redirected.
I've tried setting the file to a 307 temporary redirect, this works when the data is in the formdata but other post requests such as ones using the msxml library do not work.
Basically i need to find a way in IIS to forward a post request from one page to another without losing any of the body.
If the two pages are within the same application, you can use Server.Transfer. This just shifts the processing from the old page to the new one, and maintains all of the request data.
The best way i found was to use the temporary redirect code in IIS, although this didn't work for postdata originating from the msxml library. In the end i had to write a COM library in .NET to do the hard work using the system.encoding libraries and then reference the COM library in asp
You can always program (in asp.old) a loop that goes through all the form-data and insert a record with all the values in the database. You then redirect the user to your aspx-page with the id of the row in the database as a querystring parameter. Be careful if the form-data is sensitive, to apply some sort of security to make sure users wont "steal" others data by changing the querystring.
Redirect Reference (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/41c238b2-1188-488f-bf2d-464383b1bb08.mspx?mfr=true
Related
No duplicate of “Server.Transfer from ASP to ASP.Net” ;-)
On an IIS web server (running Classic ASP), I have a local URL that a user is remotely redirected to. Presumably, this call is made with data in the query string or transmitted through POST data. When this request is made, I need to remove this data (especially the query string) server-side, so none will be visible to the client.
For example, the user is led to http://example.com/dir/?data=payload. This is what requested, and this is what the user’s browser will display. Now I need the request resource to strip QueryString and Form data, so that the user ends up in e.g. http://example.com/dir/.
On MSDN, they have HttpServerUtility.Transfer, which adds a boolean to the classic Server.Transfer method allowing to preserve or clear data. However, when I try this in an aspx file transfering to an asp file, I get a 0x80004005 HTTP exception (“No http handler was found for request type 'GET'”).
Is it possible at all to “redirect” from an ASP.NET file to a Classic one?
Is there another, better way to remove request data server-side?
My options would be:
Use a redirect on the page without querystrings: Response.Redirect() This will clear post data as well.
Do a HTTP Request to scrape the HTML of the other page, and view it in your current page.
I would probably do option #1
I'm using Response.Redirect to serve media files, but don't want people to see the direct url to the files nor the subdomain (host). Is it possible to fake a 'get', and hide host and referer?
Use a Server.Transfer to transfer the request processing to another page.
When you use the Transfer method, the state information for all the
built-in objects are included in the transfer. This means that any
variables or objects that have been assigned a value in session or
application scope are maintained. In addition, all of the current
contents for the Request collections are available to the .asp file
that is receiving the transfer.
Server.Transfer acts as an efficient replacement for the
Response.Redirect method. Response.Redirect specifies to the browser
to request a different page. Because a redirect forces a new page
request, the browser makes two requests to the Web server, so the Web
server handles an extra request. IIS 5.0 introduced a new function,
Server.Transfer, which transfers execution to a different ASP page on
the server. This avoids the extra request, resulting in better overall
system performance, as well as a better user experience.
Since the browser doesn't make another request, the url is totally hidden from the browser, but it still gets the file that will be served by your redirect url.
What you want is not possible - for a simple reason: To have the client download the file directly from another source, you need to communicate the information about the location to the client in some way: If the client doesn't know the location, it can't download from there.
Whatever you try in the way of obfuscation, if it is decodable for the client browser, it is decodable for a human being armed with firebug.
Imagine a Web Forms application with routing.
A clean page name like:
http://www.mywebsite.com/home
Might have an underlying of URL of:
http://www.mywebsite.com/page.aspx?id=3
If a user enters http://www.mywebsiter.com/page.aspx?id=3 into a browser, I need to redirect to http://www.mywebsite.com/home
Is this possible to do?
I can't work out a way to do this as the routing engine is not executed for a physical page and in the page.aspx Page_Load method I have no way of knowing whether the URL was entered directly or was the result of a route.
You can use the Page.RouteData.Values collection to detect if the page is being loaded due to routing, rather than a direct URL. That can be done in Page_Load().
If there are route data values (you would likely check for values that you would know should exist), then they are fine. If there are no route data values, the page has loaded 'directly', and you should redirect them.
Check out the IIS URL rewrite module.
You could also look at things like disabling routing for files (RouteTable.Routes.RouteExistingFiles = false;) - that could be dangerous though!
I know that Server.Transfer() should be used to redirect to another ".aspx" page on the same server. But what is the reason behind why should I not use this method to redirect to aspx page on another server or html page?
Your answers are really appriciated.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
From : Server.Transfer vs. Response.Redirect
So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.
Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
Server.Transfer has an optional parameter to pass the form data to the new page.
Since the release version, this no longer works, because the Viewstate now has more security by default (The EnableViewStateMac defaults to true), so the new page isn’t able to access the form data. You can still access the values of the original page in the new page, by requesting the original handler:
The Server.Transfer() only works within one webapplication.
With Transfer, the "handling" of the request is internally (to the webserver/application) passed on to another page, so the Request object stays the same. This means that the processing needs to stay within the webapplication.
If you want to let processing continue on another webapplication, you will need a fresh Request there. This means that you will need have the browser issue an other request, so you need a Response.Redirect.
Server.Transfer can only happen for single HttpContext. Each virtual directory or app has its own HttpContext object and they know not that they co-exists! so you cannot do that.
Take a look at Server.Transfer Vs. Response.Redirect
Sessions is not shared among servers so that would be a big problem.
I'm replacing an old web application with a new one, with different structure.
I can not change the virtual directory path for the new app, as I have users which have bookmarked different links to the old app.
Lets say I have a user, who has this bookmark:
http://server/webapp/oldpage.aspx?data=somedata
My new app is going to reside in the same virtual directory, replacing the old one, but it has no longer oldpage.aspx, instead it has different layout, but it still needs the parameter from the old url.
So, I have set to redirect 404 errors to redirectfrombookmark.aspx, where I decide how to process the request.
The problem is, that the only parameter I receive is "aspxerrorpath=/webapp/oldpage.aspx", but not the "data" parameter, and I need it to correctly process the request.
Any idea how I can get the full "original" url in the 404 handler?
EDIT: reading the answers, looks like I did not make the question clear enough:
The users have bookmarked many different pages (oldpage1, oldpage2, etc.) and I should handle them equally.
The parameters for each old page are almost the same, and I need a specific ones only.
I want to re-use the "old" virtual directory name for the "new" application.
The search bots, etc., are not a concern, this is internal application with dynamic content, which expires very often.
The question is - can I do this w/o creating a bunch of empty pages in my "new" application with the old names, and Request.Redirect in their OnLoad. I.e. can this be done using the 404 mechanism, or some event handling in Global.asax, etc.
For the purposes of SEO, you should never redirect on a 404 error. A 404 should be a dead-end, with some helpful information of how to locate the page you're looking for, such a site map.
You should be using a 301, moved permanently. This allows the search bots to update their index without losing the page rank assigned to the original page,
See: http://www.webconfs.com/how-to-redirect-a-webpage.php on how to code this type of response.
You could look into the UrlRewritingNet component.
You should also look into using some of the events in your Global.ascx(?extention) file to check for errors and redirect intelligently. The OnError event is what you want to work with. You will have the variables from the request at that point in time (under the HttpContext object) and you can have your code work there instead of a 404. If you go this route, be sure you redirect the 404 correctly for anything other than oldpage.aspx.
I am sorry I don't have any explicit examples or information right now, hopefully this will point you in the right direction.
POST and GET parameters are only available per request. If you already know the name of the old page (OldPage.aspx) why not just add there a custom redirect in it?