У нас есть ситуация, когда у меня есть куча URL-адресов с параметрами запроса, которые используются для базового перенаправления на различные сайты, вроде короткого URL-адреса или индекса.

Пример: www.mysite.com/abc?x=123, который перенаправляет на www.google.com, www.mysite.com/abc?x=456, который перенаправляет на www.yahoo.com и так далее...

Проблема в том, что сейчас или раньше не существует фактической страницы «abc», эти ссылки были созданы и опубликованы неизвестным сайту. Теперь проблема заключается в том, чтобы найти простой способ сделать их активными, чтобы при нажатии на них выполнялись правильные перенаправления.

В настоящее время это находится на сервере IIS Windows. Сам основной сайт основан на .NET.

Есть ли способ использовать файл htaccess или аналогичный (при условии, что мы используем подключаемый модуль mod-rewrite isapi для IIS), чтобы разрешить создание этих перенаправлений? У нас есть сотни таких, чтобы создать.

Единственный другой вариант, который я могу придумать, - это перенаправить их, в свою очередь, на реальную страницу asp.net, которая затем обработает параметр и логику перенаправления в коде, предполагая, что мы можем легко перенаправить с базового URL-адреса на реальную страницу.

Настоящая проблема, я думаю, заключается в том, чтобы обойти задержку с «abc?x=456», когда фактической страницы не существует, и в любом случае не дается никакого расширения, чтобы поместить страницу на место.

0
schooner 28 Авг 2009 в 16:38

2 ответа

Вы можете использовать HTTPRedirection. Он будет делать именно то, что вы описываете: создайте фильтр для каждого каталога «abc», написав регулярное выражение для соответствия входящему URL-адресу и выведите его на страницу URL-адреса, которой вы управляете. Это произойдет до того, как прикладная часть вашего стека даже узнает об этом, и должна работать без проблем.

0
Mike Buckbee 28 Авг 2009 в 16:49

Если abc не существует, ваш сервер ответит ошибкой 404. В ASP.NET у вас есть выбор, как реагировать на это — это в файле web.config как CustomErrors. Включите это, а затем перенаправьте на причудливую страницу 404 (возможно, вы уже это сделали). Таким образом, причудливая страница 404 может проверять запрошенную строку запроса (которая передается на пользовательскую страницу ошибки как еще одну строку запроса), чтобы убедиться, что это действительное перенаправление, находится ли оно в вашей базе данных и т. д. Просто выполните Response.Redirect( ) оттуда.

Это позволяет вам поддерживать некоторую логику, хранить эти отношения в базе данных и не записывать их все в конфигурацию фильтра.

0
dnord 28 Авг 2009 в 16:51
Спасибо, теперь у нас есть 404, но мы бы предпочли, чтобы это не было обнаружено как 404 в процессе. Мы хотели бы решить это напрямую и отдельно, если это возможно.
 – 
schooner
28 Авг 2009 в 16:55
Возврат 404 в заголовке имеет некоторые плохие последствия для попадания в список поисковых систем и т. д.
 – 
Mike Buckbee
28 Авг 2009 в 22:54
Разве вы не проглотите 404, если вы аккуратно перенаправите их в Error.aspx? Я смутно припоминаю, что вы даже можете отправить 301 перед перенаправлением, чтобы поисковые системы знали, что abc?x=123 на самом деле указывает на example.com. Или к тому времени уже слишком поздно?
 – 
dnord
29 Авг 2009 в 00:53
Я считаю, что к тому времени уже слишком поздно, так как 404 является частью возврата Error.aspx
 – 
Mike Buckbee
31 Авг 2009 в 17:18