URL Rewriting/Redirects with Querystring?

问题:

We have a situation where I have a bunch of urls with query params that are used to bascially redirect to various sites, kind of like a short URL or index.

Ex: www.mysite.com/abc?x=123 which redirects to www.google.com www.mysite.com/abc?x=456 which redirects to www.yahoo.com and so on...

The issue is that there isn't an actual page "abc" now or prior, these links were created and published unknown to the site. The issue is now finding a simple means to make them active so when clicked will do the proper redirects.

This is currently on an IIS Windows server. The core site itself is .NET based.

Is there a way using an htaccess file or similar (assuming we use a mod-rewrite isapi plugin for IIS) to allow creating these redirects? We have hundreds of these to create.

The only other option I can think is redirecting these in turn to an actual asp.net page which would then process the param and redirect logic in code, assumign we can do a rredirect from the base URL to a real page easily.

The real problem I guess is getting around delaing with "abc?x=456" when there is no actual page in existence and no extension is given anyway to put a page in place.

回答1:

You can use HTTPRedirection. It will do exactly what you are describing: create a filter for each "abc" directory by writing a regular expression to match the incoming URL and output it to a URL page that you do control. This will take place prior to the application portion of your stack even being aware of it and should work seamlessly.

回答2:

If abc doesn't exist, your server will respond with a 404. In ASP.NET, you have a choice about how to respond to that - it's in the web.config as CustomErrors. Turn that on, then redirect to a fancy 404 page (maybe you already do). The fancy 404 page, then, could be checking the requested querystring (which gets passed over to the custom error page as yet another querystring) to see if it's a valid redirect, lives in your database, etc. Just do a Response.Redirect() from there.

That lets you maintain some logic, store these relationships in a database, and not write them all out to a filter config.