2010-11-10 3 views
2

У нас есть система CMS, которая создает длинные URL-адреса со многими параметрами. Мы хотели бы изменить то, как они представлены, сделать их более дружелюбными.
Поскольку у нас есть много сайтов, уже построенных на этой CMS, немного сложно переписать CMS для создания дружественных URL-адресов (хотя это метод, который мы рассматриваем, если альтернативы не найдено), мы ищем способ что когда пользователь нажимает на длинный URL-адрес, URL-адрес изменится на дружественный - в браузере - без использования Response.Redirect().
В Wordpress такой метод существует (я не уверен, что это сделано в коде или в Apache), и мне интересно, можно ли это сделать в ASP.NET 2.0 тоже.
Другая вещь, которую следует учитывать, заключается в том, что изменение между URL-адресами должно выполняться путем доступа к БД.
UPDATE: Мы используем IIS6Url переписать без перенаправления в ASP.NET

+0

Почему вы верите, что такая вещь существует в Wordpress? –

+0

Потому что я вижу, что это происходит - я вижу, что есть ссылка на сообщение, и ссылка (например): http: // domainname /? P = 2430, и когда я нажимаю на ссылку, url изменяется на включить сообщение. Я предполагаю - хотя я не уверен, что изменение выполняется без перенаправления. –

+0

Вы можете использовать скрипт или ieHttpHeaders, чтобы посмотреть на ответ. Если вы видите 301, то его перенаправление –

ответ

1

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

С точки зрения SEO, если страницы, созданные вашей CMS, имеют старые ссылки, то это то, что поисковые системы будут видеть и индексировать. Вы ничего не можете с этим сделать, javascript, перенаправление или другое. (хотя постоянная переадресация приведет вас туда немного).

Я также думаю, что то, что вы, должно быть, видели в Wordpres, было, вероятно, перенаправлением. Однако, не найдя примера, я не могу быть уверен. Дело в том, чтобы использовать Fiddler или еще один http-отладчик, чтобы узнать, что происходит, когда вы следуете одной из этих ссылок.

Для идеального SEO, когда у вас есть новые URL-адреса, работающие исходящими и входящими, то, что вы хотите сделать, это решить, что ваши новые URL-адреса являются окончательными URL-адресами. Сделайте старые URL-адреса перенаправленными на новые URL-адреса и используйте canonical link tag для нового URL-адреса из старого.

1

Я не уверен, что вы говорите здесь, но в основном страница пользователь уже читает, содержит старый, длинный, URL, и вы хотите его чтобы динамически перейти на новый короткий URL-адрес на стороне клиента, прежде чем браузер запрашивает страницу с сервера?

Единственный способ, которым я думаю, это сделать, это использовать Javascript для изменения URL-адреса в ответ на onclick или document.ready, но это было бы бессмысленно. Вам нужно будет узнать новый короткий URL-адрес для переписывания javascript, и если бы вы это знали, почему бы просто не просто перенести этот URL-адрес в ссылку?

Это похоже на то, что вы хотите маршрутизировать URL-адреса, как указано в ASP.Net 4 и 3.5?

Стандартная переадресация URL-адресов изменяет входящий объект запроса на сервере, поэтому клиентский браузер отправляет новый URL-адрес, а обработчики страницы на предыдущей странице видят старый URL-адрес. Я полагаю, что маршрутизация расширяет эту концепцию до исходящего ответа, переписывая старые URL-адреса на странице ответов в новые URL-адреса, прежде чем они будут отправлены клиенту.

Скотт Гу охватывает тему здесь: http://weblogs.asp.net/scottgu/archive/2009/10/13/url-routing-with-asp-net-4-web-forms-vs-2010-and-net-4-0-series.aspx

Скотт Гу также имеет старую запись на нормальный URL переписывания с изложением несколько различных способов сделать это. Возможно, вы могли бы расширить эту концепцию, подключившись к Application_PreSendRequestContent и вручную изменив все значения href в потоке ответов, но я бы этого не хотел. http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

+0

Спасибо. Мы не можем использовать решение маршрутизации URL, потому что мы все еще находимся в ASP.NET 2.0. Что касается старшего поста Скотта Гу, мы внедрили это решение, но оно не изменило URL-адрес в браузере пользователей. –

3

Если вы используете II7 самый простой способ сделать это состоит в использовании URL Rewrite Module По этой ссылке вы можете

Определить мощные правила для преобразования сложных адресов в простой и последовательных веб-адреса

URL Rewrite позволяет веб-администраторам легко создавать мощные правила использования переписывания поставщиков, написанные на .NET, шаблон регулярного выражения, и сопоставление подстановочных знаков для проверки информации как на оба URL, так и на другие HTTP-заголовки и переменные сервера IIS. Правили может быть написано для создания URL-адреса , которые могут быть проще для пользователей запомнить, просто для поисковых систем индекса и позволяют URL, чтобы следовать формату с последовательно и каноническим именем хоста.URL Rewrite далее упрощает процесс создания правила с поддержкой для перезаписи контента, шаблонов правил, переписать карты, проверку правильности и импорт существующих правил mod_rewrite.

В противном случае вам придется использовать методы, описанные Andrew M, или использовать Response.Redirect. В любом случае я уверен, что все эти методы приводят к отклику http 301. Я упоминаю об этом, потому что неясно, почему вы не хотите делать Response.Redirect. Это ограничение кодирования?

Обновление Поскольку вы используете IIS 6, вам понадобится использовать другой метод для перезаписи URL.

This Article от Скотта Митчелла подробно описывает, как это сделать.

Реализация URL Переписывая

URL переписывания может быть реализован либо с ISAPI фильтрами на уровне веб-сервера IIS , или с любой HTTP модулей или обработчиков HTTP на уровне ASP.NET. В этой статье основное внимание уделяется внедрению перезаписи URL-адресов с помощью ASP.NET, поэтому мы не будем вникать в особенности реализации URL-адреса с использованием фильтров ISAPI. Там , однако, многочисленные третьих сторон ISAPI фильтры, доступные для URL переписывания, такие как:

ISAPI Rewrite

IIS Rewrite

PageXChanger

и многие другие!

В статье описывается, как реализовать HTTP-модули или обработчики.

Peformance перенаправлением ответа HTTP 301, как правило, содержит только небольшое количество данных < 1K. Поэтому я был бы удивлен, если бы это было заметно. Например, разница в загрузке страницы этих адресов не noticible

"https://stackoverflow.com/q/4144940/119477"

"https://stackoverflow.com/questions/4144940/url-rewrite-without-redirect-in-asp-net"

(Я подтвердил, что с помощью ieHTTPHeaders HTTP 301 является то, что используется для изменения URL)

Page Rank

This is, что вебмастера центральный сидячей компании Google e должен сказать около 301.

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

+0

Спасибо. Я обновил свой вопрос, чтобы написать, что мы используем IIS6. Причина, по которой мы не хотим перенаправлять, состоит в том, что мы полагаем, что она будет: а) занять страницу дольше, и б) повредит ранг страницы в поисковых системах. И поскольку причина, по которой мы переходим на дружественные URL-адреса, связана с поисковыми системами, мы не хотим причинять вред той же причине. –

+0

Большое вам спасибо за подробный ответ. Однако проблема с методами, которые включают фильтры ISAPI или HTTP-модули, заключается в том, что правила написаны на уровне web.config, и нам нужен доступ к базе данных, чтобы выполнить перезаписывание. Кроме того, они не решают проблему * создания * коротких URL-адресов, они помогают только в их интерпретации, для которых у нас уже есть реализация (с использованием Context.RewritePath в Application_BeginRequest). –

+0

@Lea проблем нет. В качестве примечания, если вы пишете HTTP-модули, источник правил может быть любым, что вам нравится, его не нужно ограничивать конфигурационным файлом. Кроме того, использование RewritePath не изменяет URL в браузере, который вы указываете в качестве требования в своем исходном сообщении. Это другой вариант использования, несколько URL-адресов, указывающих на одно и то же место, но отображаемые пользователю как разные URL-адреса. –