IIS7, RewritePath и IIS лог-файлы

голоса
10

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

Я делаю это в заявке BeginRequest случае и все работает файл.

Запросы на / спорт правильно переписать default.aspx? ID = 1, и так далее.

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

Такой код работал отлично под IIS6.

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

Благодарю.

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

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

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

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

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

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

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

Задан 09/12/2008 в 18:15
источник пользователем
На других языках...                            


4 ответов

голоса
6

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

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

Это кажется очевидным сейчас, но не событие Старший Dev Инженер по IIS Core Team мысли о том, что.

Я проверил его на сессию, аутентификацию постбэк, строки запроса, ... вопросы и не нашел.

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

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

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

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

Ответил 23/02/2009 в 21:15
источник пользователем

голоса
4

Вы можете установить путь обратно к исходному значению после того, как запрос был обработан, но до модуля журнала 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()
    {

    }
}
Ответил 17/02/2009 в 19:14
источник пользователем

голоса
2

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

Ответил 17/02/2009 в 19:34
источник пользователем

голоса
0

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

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

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

б) Вызывается RewritePath в Page_PreInitслучае default.aspx, чтобы переписать URL и строку запроса , как то , что было передано в запросе (т.е.. место , которого не существует).

Например, я запросить «/ somepage /? Х = у» (который не существует).

а) правило Web.config отображает его /default.aspx

б) Page_PreInit переписывает его обратно в "/ somepage /? х = у".

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

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

Ответил 06/01/2013 в 10:54
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more