Файлы журналов IIS7, RewritePath и IIS - PullRequest
Новая
       13

Файлы журналов IIS7, RewritePath и IIS

10 голосов
/ 09 декабря 2008

Я использую Context.RewritePath () в приложении ASP.NET 3.5, работающем на IIS7.

Я делаю это в приложении BeginRequest событие, и все работает файл.

Запросы для / sports правильно переписываются в default.aspx? Id = 1 и т. Д.

Проблема в том, что в моем журнале IIS я вижу запросы GET для /Default.aspx?id=1, а не для /sports.

Этот вид кода отлично работал под IIS6.

Использование модуля Microsoft Rewrite недоступно из-за некоторой бизнес-логики, которая должна быть реализована.

Спасибо.

РЕДАКТИРОВАТЬ:

Кажется, мой обработчик находится слишком рано в конвейере, но если я перенесу логику в более позднее событие, тогда весь процесс перезаписи не сработает (слишком поздно, StaticFileHandler принимает мой запрос).

Я гуглил и гуглял, спрашивал вокруг, не могу поверить, что ни у кого нет этой проблемы?

EDIT:

Хлоп! Вот что я нашел на форуме IIS:

"Это связано с тем, что в интегрированном режиме IIS и asp.net совместно используют общий конвейер, а IIS теперь видит RewritePath, а в IIS6 его даже не замечал IIS - можно обойти это, используя классический режим будет вести себя как IIS6. "

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

Ответы [ 4 ]

6 голосов
/ 23 февраля 2009

После некоторых исследований я наконец нашел решение проблемы.

Я заменил вызовы метода Context.RewritePath () новым (представлен в ASP.NET 3.5) Context.Server.TransferRequest () метод.

Теперь это кажется очевидным, но об этом не задумывался старший разработчик в команде IIS Core.

Я проверил его на наличие сессий, аутентификации, обратной передачи, строки запроса, ... и не нашел ни одного.

Завтра я разверну изменения на сайте с очень высоким трафиком, и мы скоро узнаем, как оно на самом деле работает. :)

Я вернусь с обновлением.

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

Окончательное обновление: У меня есть это решение в производстве более года, и оно оказалось хорошим и стабильным решением без каких-либо проблем.

4 голосов
/ 17 февраля 2009

Можно вернуть путь к исходному значению после обработки запроса, но до того, как модуль ведения журнала IIS запишет запись журнала.

Например, этот модуль перезаписывает путь на BeginRequest, а затем возвращает его к исходному значению на EndRequest. При использовании этого модуля в файле журнала IIS появляется исходный путь: 

public class RewriteModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += OnBeginRequest;
        context.EndRequest += OnEndRequest;
    }

    static void OnBeginRequest(object sender, EventArgs e)
    {
        var app = (HttpApplication)sender;
        app.Context.Items["OriginalPath"] = app.Context.Request.Path;
        app.Context.RewritePath("Default.aspx?id=1");
    }

    static void OnEndRequest(object sender, EventArgs e)
    {
        var app = (HttpApplication)sender;
        var originalPath = app.Context.Items["OriginalPath"] as string;
        if (originalPath != null)
        {
            app.Context.RewritePath(originalPath);
        }
    }

    public void Dispose()
    {

    }
}
2 голосов
/ 17 февраля 2009

У меня была точно такая же проблема. Одним из способов решения этой проблемы является использование Server.Transfer вместо Context.RewritePath. Server.Transfer не перезапускает весь жизненный цикл страницы, поэтому исходный URL-адрес по-прежнему будет зарегистрирован. Обязательно передайте «true» для параметра «preserveForm», чтобы коллекции QueryString и Form были доступны для второй страницы.

0 голосов
/ 06 января 2013

Старый вопрос, но я обнаружил, что не столкнулся с вашей проблемой, когда сделал следующее:

a) Правило перезаписи в web.config направляет все запросы в /default.aspx, например: 

    <rule name="all" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*"/>
      <action type="Rewrite" url="/default.aspx"/>
    </rule>

b) Вызывается RewritePath в событии Page_PreInit файла default.aspx, чтобы переписать URL-адрес и строку запроса как то, что было передано в запросе (т. Е. Местоположение, которое не существует).

Например, я запрашиваю "/ somepage /? X = y" (которого не существует).

a) Правило Web.config сопоставляет его с /default.aspx

.

b) Page_PreInit перезаписывает его обратно в "/somepage/?x=y".

Результатом этого в IIS 7 (Express и production) является то, что журнал сервера отображает «/ somepage» для заглушки и «x = y» для запроса, а все свойства объекта Request отражают запрошенный (не существует) ) URL (что я и хотел).

Единственным странным эффектом является то, что в IIS Express элемент журнала записывается дважды. Однако в производственной среде этого не происходит (Windows Server 2008 R2).

...