aplicação do ASP.NET exibe um comportamento estranho através de firewall

Question

Este problema foi resolvido graças às suas sugestões. Veja a parte inferior para mais detalhes. Muito obrigado pela sua ajuda!

website

Nossa ASP.NET é acessado de várias específico e locais internacionais altamente seguras. Tem sido muito bem operar, mas nós adicionamos outro local cliente que está exibindo um comportamento muito estranho.

Em particular, quando o usuário insere critérios de pesquisa e clica no botão pesquisar a lista resultado retornos esvaziar. Nem sequer mostrar o texto '0 resultados retornados', por isso é como se o controle Repeater não ligar em tudo. Comportamento semelhante aparece em alguns, mas não todos, outras partes do site. O usuário é capaz de fazer login para a multa local e suas informações de perfil é exibida.

Eu tenho ligado para o site localmente usando exatamente as mesmas credenciais como eles e o site funciona bem a partir daqui. Passamos por as etapas com cuidado, por isso estou confiante de que não é uma questão de usuário.

os resultados da pesquisa na Page_Load da página de resultados de pesquisa a primeira vez que é carregado (o critério é na cadeia de consulta) I bind. i.

if (!IsPostBack) {
  BindResults();
}

I pode replicar exatamente o mesmo comportamento localmente por comentar as BindResults () chamada de método.

Alguém sabe como o valor de IsPostBack é calculado? É possível que a sua configuração de firewall altamente segura causaria IsPostBack sempre retornar verdadeiro, mesmo quando é um redirecionamento de outra página? Isso poderia ser um arenque vermelho como o problema pode estar em outro lugar. Ele faz exatamente replicar o resultado embora.

Eu não tenho acesso ao site, para solução de problemas é restrito a dar-lhes instruções e pedir-lhes para me dizer o resultado.

Obrigado pelo seu tempo!

info anexados: client está atrás de um Microsoft ISA 2006 firewall regras padrão em execução. O site foi adicionado ao Internet Explorer lista de sites confiáveis ??e tentei no Firefox e Google Chrome, todos com o mesmo resultado.

Solução : O vencedor para mim foi a sugestão de usar Fiddler. O que uma excelente ferramenta que nenhum desenvolvedor web deve ser sem. Usando este eu era capaz de tirar vários cabeçalhos do pedido até que eu reproduzido o problema. Havia realmente dois fatores que causaram esse bug, como é frequentemente o caso com essas questões confusas.

Fator um - Sempre que possível a aplicação web usa compressão GZIP como suportado por todos os principais navegadores. O firewall foi tirando o cabeçalho que especifica gzip apoio descompressão (Accept-Encoding: gzip, deflate).

O fator dois - Um bug no meu código significava que algum processamento foi ultrapassado quando o conteúdo estava sendo enviado descompactado. Este problema não foi notado antes porque o aplicativo é utilizado por um público limitado, todos os quais apoiaram GZIP descompressão.

Answer 1

Se eles estão em todos os tech-savvy, gostaria de tê-los baixar Fiddler ou algo semelhante, capturar toda a sessão HTTP, e em seguida, enviar-lhe a sessão salva. Talvez alguma coisa lá dentro vai ficar fora.

Enquanto isso, veja se você pode obter uma instalação do ISA Server (instalar uma avaliação, se você tem que, ou um do MSDN se você tem ou conhece alguém com um sub) e veja se você pode replicar-lo localmente.

Answer 2

É possível que o cliente tem desactivado Javascript e ele não está pegando o valor forma _EVENTTARGET?

Answer 3

Pode ser algum tipo de procuração que cria uma solicitação de sair de uma determinada solicitação POST ...

Eu não sei como o IsPostBack é calculado, mas meu palpite seria que ele verifica o pedido HTTP para ver se é um POST ou GET ...

Answer 4

Ohh, sim. É definitivamente não é "_EVENTTARGET" BTW ...

Eu sei isso desde Ra-Ajax não passar qualquer um desses parâmetros para o servidor e eles (Ra pedidos -ajax) são processados ??como IsPostBack pede ...

Answer 5

Localização, localização, localização. Verifique a cultura do usuário. Normalmente, que as questões de causas.

Answer 6

Você pode criar um teste post página que passa as mesmas coisas que a sua página de pesquisa faz, e na gravação Page_Load de volta todo o posto para se certificar de que eles estão ficando passado, particularmente a __VIEWSTATE.

foreach (string key in Request.Form)
{
    Response.Write("<br>" + key + "=" + Request.Form[key]);
}

Em seguida, pedir um dos usuários de transmitir de volta o que ver em que página de teste.

EDIT: Existe documentação que alguns firewalls podem corromper o VIEWSTATE e alguns métodos para contornar o problema: Ver Estado Overview

Answer 7

Verifique os logs do IIS para ver se o pedido ainda torna ao seu servidor. A configuração ISA pode ser cache o pedido inicial e servindo-se que nos pedidos seguintes.