IIS7, RewritePath e IIS arquivos de log

votos
10

Eu estou usando Context.RewritePath () em ASP.NET 3.5 aplicativo em execução no IIS7.

Eu estou fazendo isso na aplicação BeginRequest evento e tudo funciona arquivo.

Os pedidos de / esportes estão correctamente reescrito para default.aspx? Id = 1, e assim por diante.

O problema é que no meu log IIS vejo GET pedidos de /Default.aspx?id=1 e não para / de esportes.

Este tipo de código funcionou perfeitamente sob IIS6.

Usando o módulo Rewrite Microsoft não é uma opção, devido a alguma lógica de negócios que tem de ser implementado.

Obrigado.

EDITAR:

Parece que meu manipulador é muito cedo no pipeline, mas se eu mover a lógica para um evento mais tarde, que a coisa toda reescrita não funciona (que seja tarde demais, StaticFileHandler pega meu pedido).

Eu pesquisei e pesquisei, perguntou ao redor, não posso acreditar que ninguém tem esse problema?

EDITAR:

Caramba! Aqui está o que eu encontrei no fórum IIS:

Isso ocorre porque no modo integrado, IIS e compartilhar asp.net um gasoduto comum ea RewritePath é agora visto pelo IIS, enquanto em IIS6, não foi sequer visto pelo IIS - você pode resolver isso usando o modo clássico, que se comportaria como IIS6.

Atualização final : Por favor, dê uma olhada em minha resposta abaixo , eu tenho atualizado com resultados após mais de um ano em ambiente de produção.

Publicado 09/12/2008 em 18:15
fonte usuário
Em outras línguas...                            


4 respostas

votos
4

Você pode definir o caminho de volta para o valor original após a solicitação foi processada mas antes do módulo de registro IIS escreve a entrada de log.

Por exemplo, este módulo reescreve o caminho em BeginRequeste em seguida, define-lo de volta ao valor original no EndRequest. Quando este módulo é utilizado o caminho original aparece no arquivo de log do 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()
    {

    }
}
Respondeu 17/02/2009 em 19:14
fonte usuário

votos
2

Eu tinha exatamente o mesmo problema. Uma maneira de contornar isso é usar Server.Transfer em vez de Context.RewritePath. O Server.Transfer não reiniciar o ciclo de vida de página inteira para que o URL original ainda será registrado. Certifique-se de passar "true" para o parâmetro "preserveForm" para que as coleções QueryString e Form estão disponíveis para a 2ª página.

Respondeu 17/02/2009 em 19:34
fonte usuário

votos
6

Depois de alguma pesquisa, eu finalmente encontrei uma solução para o problema.

Eu substituí as chamadas para Context.RewritePath método () com o novo (introduzido no ASP.NET 3.5) Context.Server.TransferRequest () método.

Parece óbvio agora, mas não evento Engenheiro Senior Dev no IIS Núcleo pensamento equipe de isso.

Eu testei-o para a sessão, autenticação, postagem, querystring, ... questões e não o achou.

Amanhã eu vou implementar a mudança para um site de tráfego muito hight, e em breve saberemos como ele realmente funciona. :)

Eu estarei de volta com a atualização.

A atualização: a solução ainda não é inteiramente sobre os meus servidores de produção, mas é testado e ela não funciona e, tanto quanto eu posso dizer até agora, é uma solução para o meu problema. Se eu descobrir alguma coisa na produção, vou postar uma atualização.

A atualização final: Eu tenho esta solução em produção há mais de um ano e que tem provado ser uma solução boa e estável sem quaisquer problemas.

Respondeu 23/02/2009 em 21:15
fonte usuário

votos
0

questão de idade, mas eu descobri que eu não encontrar o seu problema quando eu fiz o seguinte:

a) A regra de reescrita em web.config para direcionar todas as solicitações para /Default.aspx, por exemplo:

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

b) Chamado RewritePath no Page_PreInitcaso de default.aspx, para reescrever o URL e querystring como o que foi passado no pedido (ie. a localização que não existe).

Por exemplo, eu peço "/ somepage /? X = y" (que não existe).

a) regra Web.config mapeia para /Default.aspx

b) Page_PreInit reescreve-lo de volta para "/ somepage /? x = y".

O resultado deste, no IIS 7 (Express e produção) é que o log do servidor reflete "/ somepage" para stub e "x = y" para consulta, e todas as propriedades do objeto de solicitação refletir a URL solicitada (inexistente) ( que é o que eu queria).

O único efeito estranho é, no IIS Express, o item de log é gravado duas vezes. No entanto isso não acontece na produção (Windows Server 2008 R2).

Respondeu 06/01/2013 em 10:54
fonte usuário

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