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.
Related
Is it possible to post data from an asp.net application in one domain to another application on a different domain?
I've seen some of the posts where people mention some rather strange ways to inject forms into the response stream, but this seems overkill.
Is it possible and what is the best way to achieve it without hacking Asp.net to death?
Thanks,
Jacques
It's absolutely possible, and pretty easy to do.
Browser posts data to your .net app
Your app uses the HttpWebRequest object to post data to the 3rd party site
3rd party site gives data back to your app or simply accepts post.
Your app responds to the browser with whatever you need.
I have no idea why you would "inject forms into the response stream" or do anything funky like that. Perhaps you could add a bit more about your requirements.
Chris.
If you have access to both applications then the best way is to do it server side.
So make a web service available and consume it from the posting application.
or
Use httpwebrequest server side, see link below.
http://www.netomatix.com/httppostdata.aspx
On the client you could use a library such as http://easyxdm.net/wp/ - though there is a bit of a learning curve.
Here are a couple of links that may help you if you dont want to use the above routes and are prepared to edit your asp.net pages.
http://blog.dmbcllc.com/2009/11/11/asp-net-cross-domain-form-submission/
Cross-Domain Posting in ASP.Net loses Form Fields
First off i'll advise i'm not familiar with implementing url re writing on any level.
That said I do know there are 2 types or rewrites setup for this site.
One I can locate and is solely responsible for top level rewrites (turning .com to .co.uk)
There is another rewriter implemented somehow somewhere, very early on in a pages lifecycle and I cannot find how or where the site is doing this. It's possible it's all handled in a 3rd party DLL but I would like to know the steps I might go through to prove or disprove this.
Thanks
What does your web.config have registered in the httpModules section? Often URL Rewriters are registered very early in the request life cycle. httpModules and httpHandlers can grab the request here. This is of course assuming you've ruled out IIS redirects. After that you can look for manual redirection in the global.asax file. There are a lot of places to look when you don't know how the original coder decided to implement the idea. I've seen some bad places, including in the constructor of a common base page inherited by every page on the site.
URL rewriters are typically ISAPI filters - you can search currently applicable ISAPI filters on Web Site or Folder properties in IIS 6 (you might have ISAPI filters in right context menu), on II7, ISAPI filters in features view when you select web site or folder.
With .NET 3.5 or 4.0, its possible that ASP.NET routing might be the reason - you can locate that in web.config or global.asax (common places for putting the routes).
My word i'm so sorry after finally tracking down an original dev there is no re-writes whatsoever. The solution is complex but workable. Weird etc :). Love IT.
We have a WCF service in our web application which is being called by browser through ajax(jquery and asp.net scriptmanager)
In this service some of the methods are WebGet and some of them are WebInvoke
Problem is now any request to WebInvoke method through asp.net scriptmanager is making request using http 'OPTIONS' instead of 'POST'. And webserver is going to deny this request as it don't allow OPTIONS
POST should be default for WebInvoke attribute when no method is defined.
We started having this problem since last couple of weeks just spotted today. We upgraded everything to .net 4.0 around same time so not sure .net 4.0 has something changed.
Also weird thing is everything works fine when using website like xyz.com we only see problem when using www.xyz.com
Any idea what it could be?
Edit: Ok got little closure
Problem is Asp.net scriptmanager does not allow cross site reference in ajax.
But wait we do not do anything that calls cross site.
What i found is when i use www.a.com some how js files generated by script manager wants to use a.com not www.a.com.
Any idea how to resolve this?
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.
I was planning to use url routing for a Web Forms application. But, after reading some posts, I am not sure if it is an easy approach.
Is it better to use the URL Rewrite module for web forms? But, it is only for IIS7. Initially, there was some buzz that URL routing is totally decoupled from Asp.Net MVC and it could be used for web forms.
Would love to hear any suggestions..
This is the best article I found about this topic: IIS URL Rewriting and ASP.NET routing by Ruslan Yakushev.
IIS URL Rewriting
When a client makes a request to the Web server for a particular URL, the URL-rewriting component analyzes the requested URL and changes it to a different other URL on the same server. The URL-rewriting component runs very early in the request processing pipeline, so is able to modify the requested URL before the Web server makes a decision about which handler to use for processing the request.
ASP.NET Routing
ASP.NET routing is implemented as a managed-code module that plugs into the IIS request processing pipeline at the Resolve Cache stage (PostResolveRequestCache event) and at the Map Handler stage (PostMapRequestHandler). ASP.NET routing is configured to run for all requests made to the Web application.
Differences between URL rewriting and ASP.NET routing:
URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are some functional differences between IIS URL rewriting and ASP.NET routing:
The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.
There's a great post here about the differences between the two from a member of the IIS team.
One caveat I would advise is that for WebForms, you need to be careful when using Routing. I've written a sample implementation of how you'd use routing with WebForms that addresses these concerns and hopefully helps answer your question.
Do you want formatted urls to be a factory for spawning pages?
or do you want to make the .aspx go away?
rewriting, is for making the .aspx go away, or just to tidy up the url.
Routing, is for looking at a request and determining which object should handle it. They sound similar, phil haack has a few good articles on the subject.
in iis6, isapiRewrite, is very good
I recently just wrote my own rewriting system to make the URLs on my sites look better. Basically, you're going to need to write your own IHttpModule and add it to your web.config to intercept incoming requests. You can then use the HttpContext.Current.RewritePath to change what you're pointing at.
You'll also want to configure your site to use the aspnet_isapi for everything.
You'll discover a lot of little problems along the way like trying to work with pages that use "tails" on them (like for PageMethods), or pathing of page elements and form postbacks, but you'll get through them.
If interested, I can post a link to the code and you can check it out. I've worked a lot of the problems out already so you can read through it as you go. I'm sure there are a lot of other people that have done this as well that might be good resources as well.
You may want to check out my answer to this question: ASP.NET - Building your own routing system. I include some good references to help build your own routing system with either using the url rewriting method or the new routing engine that you can use that came out of the ASP.NET MVC project.
The Dynamic Data project that is available with .Net 3.5 SP1 shows a good example of a url routing implementation.
For URL Rewriting on IIS, IIRF works in IIS5, 6, 7. Free. Easy. Fast. Open Source. Regular expression support.