O IIS6 tem um proxy secreto, não logado, transparente e sensível a maiúsculas e minúsculas?

Question

O IIS tem um proxy secreto, não logado, transparente e sensível a maiúsculas e minúsculas embutido?

Existe um arquivo no servidor web:

GET http://www.stackoverflow.com/javascript/ModifyQuoteArea.js HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.stackoverflow.com


HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 29246
Date: Mon, 07 Mar 2011 14:20:07 GMT
Content-Type: application/x-javascript
ETag: "5a0a6178edacb1:1c51"
Server: Microsoft-IIS/6.0
Last-Modified: Fri, 02 Tue 2010 17:03:32 GMT
Accept-Ranges: bytes
X-Powered-By: ASP.NET

...

O problema é que as alterações feitas no arquivo não serão exibidas, a versão antiga (por exemplo, fevereiro do ano passado) continua sendo exibida:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 29246
Date: Mon, 07 Mar 2011 14:23:07 GMT
Content-Type: application/x-javascript
ETag: "5a0a6178edacb1:1c51"
Server: Microsoft-IIS/6.0
Last-Modified: Fri, 02 Tue 2010 17:03:32 GMT
Accept-Ranges: bytes
X-Powered-By: ASP.NET

...

O mesmo arquivo antigo é exibido, embora tenhamos:

• renomeou o arquivo
• excluiu o arquivo
• reiniciado IIS

A solicitação deste arquivo não aparece nos registros do IIS (por exemplo, C:\WINNT\System32\LogFiles\W3SVC7\ )

E isso só acontece do lado de fora (ou seja, a internet). Se você emitir a solicitação localmente no servidor, você irá:

• obtenha o arquivo atual (arquivo lá)
• 404 (arquivo renomeado)
• 404 (arquivo excluído)

Mas se eu alterar o caso do recurso solicitado, por exemplo:

GET http://www.stackoverflow.com/javascript/MoDiFyQuOtEArEa.js HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.stackoverflow.com

Note: MoDiFyQuOtEArEa.js verses ModifyQuoteArea.js

Em seguida, eu faço obter o arquivo adequado (ou obter o 404 como espero se o arquivo for renomeado ou excluído).

Mas quaisquer alterações subsequentes no arquivo não serão exibidas até que eu altere o caso do arquivo que estou solicitando.

Os logs do IIS não mostram atividade quando o site da Web exibe um dos misteriosos arquivos armazenados em cache. Solicitações para outros arquivos (ou seja, ASP) (ou usando o truque alterar-pedido-recurso-caso-desvio-transparente-cache ) aparecem nos logs do IIS e mostram a fonte apropriada endereço IP do cliente (ou seja, não o endereço de algum proxy intermediário misterioso).

• Como o arquivo não existe mais no disco rígido, concluo que existe um proxy.
• As solicitações atendidas por esse proxy não são registradas nos logs do IIS.
• As solicitações de novos arquivos são registradas e, a partir do IP do cliente, não de um proxy IP.
• O proxy é sensível ao caso.

Isso não soa como algo que a Microsoft, ou o IIS, faria:  - um proxy transparente?  - case-sensitivie?  - sem registro?  - sobreviventes de reinícios do IIS?  - sobrevivendo em um cache por horas?

não acredito que o IIS do nosso cliente esteja fazendo essas coisas. Eu estou supondo que há algum outro proxy transparente na frente do IIS.

Ou o IIS tem um:

• transparente,
• sem registro,
• sensível a maiúsculas e minúsculas
• baseado em memória

proxy, que armazena conteúdo por pelo menos 7 horas?

    

Answer 1

Se a solicitação não aparecer nos logs do IIS, ela será servida por um cache em algum lugar, no cache local do cliente ou em um cache (proxy) em algum lugar da cadeia de solicitações.

Veja os cabeçalhos de resposta de uma solicitação no lado do cliente e veja se há% head_de% cabeçalhos lá. Um Via: header indica que existe um proxy na cadeia e deve haver um cabeçalho para cada proxy na cadeia (assumindo que os proxies estão se comportando). Se você vir um ou mais, é uma boa chance de o conteúdo ser veiculado em um cache.

    

Answer 2

Antes de usar meu chapéu de papel alumínio e declarar que deve haver um proxy super-secreto que ninguém conhece, peço ao cliente para verificar as configurações do navegador. Se eles estão usando o IE, isso soa um pouco como "Verificar novas versões de páginas armazenadas: nunca" (também pode ser "toda vez que eu iniciar o IE" se o cliente já não reiniciar o IE como parte da solução de problemas). / p>     

Answer 3

Tente curl -v link , se você ainda ver a versão antiga, há um cache compatível com HTTP configurado incorretamente o caminho do cliente para o servidor. Se você vir a versão atual, seu navegador será responsabilizado

    

Answer 4

Sooo a resposta é "não deveria".

Resposta mais longa na forma de uma pergunta: o comportamento do proxy que você está exibindo é muito semelhante a um proxy, pois o nome do host faz parte da solicitação. Você está tratando o servidor como um proxy ou está apenas captando o tráfego de um proxy?

Normalmente, quando os clientes solicitam conteúdo, eles solicitam um URL relativo e fornecem um cabeçalho Host :.

Um cliente solicita um servidor proxy para link apenas quando o destino é configurado como proxy , e eu Tive que depurar um comportamento estranho baseado nisso antes.

Então, a partir disso, podemos dizer com alguma certeza que você tem um proxy em algum lugar do mix. Fiddler, que funciona como proxy, conta.

Eu sugeriria, como Ochoto, testar o Curl, o WFETCH, o WGET ou qualquer outro cliente simples, ininterrupto-por-WinInet-ou-navegador-de-configurações-ou-proxy-cache do cache do IE para ser absolutamente certo.

Na verdade, se você quiser certeza absoluta:

• Captura de rede em execução no cliente
• Captura de rede simultânea no servidor
• Uso de um cliente de navegador para solicitar o dito conteúdo
• Uso de um cliente sem navegador para solicitar o mesmo conteúdo
• Se você tivesse o IIS 7, o registro do FREB para a URL seria realmente muito bom
• Idealmente, a capacidade de percorrer o servidor da Web enquanto processa cada extensão; caso contrário, algo como IISTrace

Se você realmente quiser, pode usar o rastreamento HTTP.SYS também, apenas para uma boa medida.

Se

• você vê a solicitação atingir o servidor e
• o servidor envia uma resposta e
• essa resposta é categoricamente Não registrada pelo servidor e
• não existem filtros ISAPI que possam ter decidido que o log foi então 1999, ou
• apenas engasgado e
• não foram molestados por antivírus em algum <> estranho-que-arquivo-manipular-é-válido-não-que-não-ha-tem-você-é-depois-de-todos caminho e
• nenhuma exceção ocorreu em manipuladores gerenciados que não devam estar em execução para arquivos estáticos, mas, por algum motivo, ainda estão mapeados para manipulá-los

Então, então , então então , hum, oh desculpe, eu perdi minha linha de pensamento.