A site uses this link format for everything:
example.com/?article=123
example.com/?category=456
example.com/?article=789&picture=012
An ASP classic default.asp catches all of this and does stuff with it.
I would really like to create a couple of routes for these old type of Url's with querystrings on the root, so I can catch them in a separate controller and do some tricks on them (permanent redirects).
When I try to create a route that contains a questionmark, I am told that is not possible.
This could be a good case for Global Action Filters if there's no way to handle these using routes (Although I imagine there is).
You could process the incoming url in the OnActionExecuting method and redirect as appropriate.
UPDATE
There's a good SO answer here on how to redirect as you require. It may not be exactly as you've asked however a similar principle should acheive what you're after quite easily.
Related
I am using Spring Mvc.Here I have used JSP as a view.
I have a situation,in which I have to redirect to another form which is subjected to another controller,from a form which is subjected to another controller
I have used
<c:redirect url="updateStock.ic?appId='${mineralSelect.applicationId}'&serviceId='${mineralSelect.serviceId}'&mineralIdAndName='${mineralList.get(0).mineralId}:${mineralList.get(0).mineralName}'"/>
But it is executed,but the page is not rendered.But in the console view there is no exception page.
Since I didn't get an answer to my comment, I will try to give you the best answer with limited knowledge that I possibly can.
First, I think it's bad practice to put redirects in your JSPs. Frankly, I think its bad practice to put anything other than simple loops and decision branches in your JSPs. I would consider the decision to do a redirect a "business logic" decision, and one I would not make in my JSP. Spring MVC provides several methods to do a redirect in the controller, which has the added benefit of not being in the JSP, and would bypass having to render the JSP to perform the redirect. This posting has some examples of how to perform a redirect in the controller.
If you still have your heart set on doing the redirect in your JSP, then I would suggest breaking out some testing tools to see if you are getting the redirect at all. Chrome's Developer Tools and Firefox's Firebug have the ability report what gets sent to your browser. Fiddler is also a good tool for these things. What you are looking for is an HTTP 3xx header, most likely a 302, with the URL that you are trying to redirect to.
If you are not seeing the HTTP 3xx response in the browser, then its time to troubleshoot. Start by asking the following:
Is the JSP ever rendering at all
If it is rendering, what happens if I put debug statements around my redirect?
Is there some logic around my redirect that is causing it to not even get executed (debug statements might elude to this)
Start as close to the source as possible, adding debug prints and logging, then expand out to the next widest area until you determine what is working and what is not working.
I have some functionality in the code behind, which after executing needs to forward the request to another page. I want to pass along data like you would by setting a request attribute in Java (i.e. - I don't want it in the query string of the redirected response). Is this possible with ASP.NET (c#)?
You can use Server.Transfer if you want to forward the request and keep all of the Request variables, or you can use Session.
Are you using ASP.NET Webforms or MVC? The following will redirect your request to a new page. You'll have to test and see if it forwards post data (I'm not sure). Now that you mention it, I don't think ASP.NET has a built in "forward:" request like java does. I think it just has "redirect" for security reasons. (Someone correct me if I'm wrong).
In Webforms:
try Response.Redirect("mynewpage").
In MVC:
at the completion of your action method return Redirect("mynewpage")
I don't know your use case, but it is generally not good practice to pass post data to a different page/request. Typically the posted action will take care of persistence, and then a GET request will be issued to the redirect page. If the redirected view needs access to the posted data, it should go to the persistence mechanism (DB) to retrieve it. This method is more secure, and generally better practice. This is a very general guideline, so use it as your needs allow.
HTH
Yes - See the reflection code at:
HttpModule to add headers to request
However - the question is - do you really want to use request headers? probably not. its a hack to use them. If you simply want to pass information, use the Context.Items dictionary to transfer your items between requests with Server.Transfer.
Depending on what you are doing and where your events are, you can also make use of Cross Page Postback.
See http://msdn.microsoft.com/en-us/library/ms178139.aspx
Otherwise, I'd go with vcsjones answer of Server.Transfer
So... I've got an ASP.NET app. Let's assume I configure IIS to always point to the same file, index.aspx. Let's say I want to write all my code in C# and then return some HTML I generated in the C#. How do I do that?
Would I just have 1 file with 1 line of code,
<%# Page CodeBehind="mycode.cs"
Is it necessary to have such a "useless" file? I can't direct the request straight into the code-behind?
Secondly, where are some good tutorials on code-behinds? Specifically, I see this Page_Load event that I guess gets called automatically?
Are there other events? What are they?
Also, how would I access things like POST data, or the request URL?
How would I return a HTML response? Or a 404?
I'm seeing a lot of tutorials on "inline" ASP, but I don't really care about that.
Sounds like you want a generic handler. They are available in the New Item... dialog. This will give you a .ashx file where you can handle incoming web requests just like you would in your scenario, but in a cleaner way. Using these you can return any kind of HTTP response, including HTTP errors. You have full access to the HTTP context for POST data, URL parameters, cookies, etc. See more here.
Another alternative is to implement IHttpHandler yourself, although with generic handlers there isn't much point in going through the effort.
Are there other events? What are they?
There is a whole lot of Events available when you inherit from System.Web.UI.Page. You can see them http://msdn.microsoft.com/en-us/library/ms178472.aspx
Also, how would I access things like POST data, or the request URL?
this.Request.Form, would let you access the PostData from a page. this.Request.Url would let you access the url.
How would I return a HTML response? Or a 404?
You can override the Render method of the page to provide HTML Response. You can throw a HttpException(404, "file not found") to return 404.
After going through your questions, you most likely need ASP.NET MVC rather than ASP.NET webforms or you can use a handler as suggested by Martin
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'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?