Как определить, произошла ли перезапись ISAPI

Я унаследовал старую систему после того, как начал новую работу, никто из предыдущих разработчиков здесь больше не работает, и никто из них так много не документировал. Веселые времена.

В системе используется старая, несуществующая CMS, и я только что закончил большое испытание, в результате которого я не мог понять, как работает маршрутизация (клиент хотел изменить URL-адрес). Позже выяснилось, что предыдущие разработчики использовали совершенно отдельную программу под названием «Helicon ISAPI rewrite» и выполняли все управление URL-адресами сайта оттуда.

Мой вопрос: как я мог понять это быстрее (например, есть ли внешние инструменты, которые я мог бы использовать, или журналы, о которых я не знаю, которые показали бы, как работает эта маршрутизация)?

Я провел целый день, копаясь в коде за 10 лет, а ответа там даже не было! Прямо сейчас я чувствую, что у меня не было шанса понять это быстро, но мне интересно, не упустил ли я что-то.


person Mikey Hogarth    schedule 05.09.2012    source источник


Ответы (2)


Думаю, я понимаю, о чем вы просите, в первую очередь, обнаружить переписывание. Ответ Тони верен, если вы знали об ISAPI_Rewrite заранее, но задним числом 20-20. Я большой поклонник ISAPI_Rewrite и Helicon Ape, так что мог подозревать об этом. Однако, если бы переписывание выполнялось с помощью .NET web.config IIS7, я бы не смотрел туда (хотя я думаю, что web.config должен быть местом для начала всего, связанного с IIS). С устаревшей CMS или чем-то вроде WordPress я бы не знал, с чего начать, поэтому я, вероятно, начал бы с кода, как вы.

Я полагаю, что реальная отправная точка — это вершина IIS, еще до того, как запрос попадет в веб-код.

Осматриваясь в IIS7, я вижу Handler Mappings с целой кучей вещей, перехватывающих различные запросы. Все они могут «делать что-то» с запросом до того, как он попадет на веб-сайт. например, я вижу Microsoft ExtensionlessUrlHandler..., который доставил нам проблемы как критическое изменение при обновлении до .NET 4.0. Нам пришлось покопаться в этом, задаваясь вопросом, что помещает eurl.axd в наши URL-адреса.

IIS6 имеет вкладку «Фильтры ISAPI» в свойствах веб-сайта. У меня есть ISAPI_Rewrite и ASP.NET_2.0.... в нем. Также есть таблица заголовков HTTP с типами MIME, которые могут быть причиной отклонения запросов.

Зная это сейчас, возможно, список всего программного обеспечения для перезаписи был бы удобен. Просто найдите в системе любой из них, установленный — возможно, это самый быстрый способ получить первую подсказку.

И на самом деле, если вы потратили полдня за 10 лет написания кода, это не так уж и плохо! Так что у вас, возможно, не было возможности быстро понять это - любая устаревшая система будет иметь спрятанные секреты.

person goodeye    schedule 30.11.2012

Если это ISAPI_Rewrite v3, вы можете включить ведение журнала в httpd.conf в папке установки ISAPI_Rewrite, вставив следующие строки:

RewriteLogLevel 9
LogLevel debug

Затем, после того как вы сделаете тестовый запрос, файлы rewrite.log и error.log появятся в папке установки ISAPI_Rewrite. error.log показывает общие проблемы, в то время как rewrite.log показывает, как и применяются ли правила и каков результирующий URL-адрес.

person TonyCool    schedule 05.09.2012
comment
Спасибо за ответ - это не столько запись в журнал, когда он там, я хочу знать, как я мог узнать, что он там (например, какие трассировки и т. д. я мог использовать для идентификации этого ISAPI происходила перезапись). - person Mikey Hogarth; 05.09.2012