2009-05-07 21 views
25

Esta pregunta es una derivación/evolución de this question. (Esa pregunta se marcó como resuelta porque puse una recompensa en ella y se resolvió automáticamente, pero en realidad nunca obtuvo respuesta.)IE 8 soltar páginas de memoria?

El resumen es este: tenemos un sitio ASP.NET. Algunas veces obtenemos errores cuando el cliente solicita URL extrañas. De los recursos que el cliente está solicitando, parece que falta un bloque de texto 4k de la fuente html.

Un ejemplo sencillo ... si tenemos una página que tiene este aspecto:

<a href="myValidLink.aspx">Here's some text</a> 
a bunch more stuff 
...(a large block of text)... 
AND NOW MORE STUFF LATER 

El cliente puede pedir la url: "myValidLiORE% 20STUFF% 20LATER".

Actúa como si una sección de la fuente html simplemente no estuviera allí ... y esa sección que falta parece ser exactamente 4KB (4096 bytes) de largo (o según algunas personas, a veces 1KB?).

Lamentablemente, no podemos replicar este error a pedido, aunque vemos que viene de clientes muchas veces al día.

Al principio pensamos que esto era un problema con Webresource.axd, porque lo vimos mucho allí ... pero ahora creo que fue principalmente porque estábamos agrupando errores similares juntos, y esos errores tendían a ocurrir cuando la corrupción ocurrió en esa área en particular. Ahora que estoy viendo una gama más amplia de problemas, veo lugares en los que obtenemos errores muy diferentes que parecen estar causados ​​por el mismo problema de omisión.

Hemos visto esto mucho con IE 8, y se ha vuelto más frecuente a medida que IE 8 se ha vuelto más frecuente. Lo vemos ocasionalmente con un navegador que se informa a sí mismo como IE 7 ... que IE 8 hará si se pone en "modo de compatibilidad".

Mi teoría, en este punto (que estoy tratando de encontrar una forma de probar) es que el servidor web está enviando correctamente todos los datos en la secuencia de bytes ... y que el navegador, IE 8 , tiene un problema y descarta una página de memoria (4k) bajo ciertas condiciones.

Estoy un poco preocupado por esta teoría, sin embargo, dado que aparentemente algunas personas han informado de esto "ocasionalmente" con IE 6 o FF 3 ... estos tienden a ser atípicos, y podrían ser solo problemas diferentes con similares síntomas, pero si es realmente lo mismo en esos navegadores, eso haría volar mi teoría fuera del agua. Aún así, no tengo una mejor idea en este punto.

Otra idea que he tenido es que tal vez un paquete de servicio relativamente reciente en el servidor está causando problemas con los datos que se sirven a los clientes, cayendo ocasionalmente 4KB. El problema con esta teoría es que no explica la gran preponderancia de los errores en IE 8 y la falta de ellos en otros navegadores de cliente.

Así, las preguntas que se espera con el tiempo tendrán respuestas:

  1. Alguien más ha encontrado esto? (¿Tal vez ahora que está en su radar?)
  2. ¿Alguien puede replicar este problema de forma consistente?
  3. ¿Alguna idea de lo que es? ¿Puedes verificar o refutar mi teoría?
  4. ¿Hay alguna solución o solución alternativa?
+1

Actualización: El error 4k ahora se corrigió mediante la actualización acumulativa de IE8 el 3/30/2010. http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx – EricLaw

Respuesta

12

** Editar 4/1/10: ** Actualización: El error de 4k ahora está corregido por la actualización acumulativa de IE8 el 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/

El equipo de Internet Explorer ha estado investigando este problema.

- Impacto = = -

Hasta el momento, creemos que el problema no tiene impacto en la experiencia del usuario final con la aplicación web; el único efecto negativo son las solicitudes espurias/malformadas enviadas por el motor de descarga especulativa de JavaScript. Cuando el analizador realmente necesita el script, se descargará y usará correctamente en ese momento.

- = Circunstancias = -

La espuria-petición parece ocurrir sólo en ciertas situaciones de tiempo, sólo cuando el pre-analizador se ve obligado a reiniciar (como cuando una etiqueta http-equiv META contiene un tipo de contenido con una directiva CHARSET aparece en el documento) y solo cuando una URL SRC de JavaScript abarca el 4096o byte del cuerpo de respuesta HTTP.

- Solución = = -

Actualmente Creemos que este problema generalmente puede ser mitigado por la que se declara el juego de caracteres de la página utilizando la cabecera HTTP Content-Type en lugar de especificar dentro de la página.

Así, en lugar de poner

[meta http-equiv = "Content-Type" content = "text/html; charset = UTF-8"]

En su etiqueta de la cabeza, en cambio, enviar el siguiente encabezado de respuesta HTTP:

Tipo de contenido: text/html; charset = utf-8

Tenga en cuenta que la especificación del juego de caracteres en el encabezado HTTP mejora el rendimiento en todos los navegadores, ya que los analizadores del navegador no necesitan reiniciar desde el principio al encontrar la declaración del juego de caracteres. Además, usar el encabezado HTTP ayuda a mitigar ciertos vectores de ataque XSS.

+1

http://blogs.msdn.com/ieinternals/archive/2009/07/27/ Bugs-in-the-IE8-Lookahead-Downloader.aspx – EricLaw

+0

La configuración de un encabezado HTTP en IIS lo usa para todas las solicitudes, incluso para hojas de estilo e imágenes. ¿Hay alguna forma de hacerlo sin configurarlo en IIS? – goldenratio

+1

Puede usar un filtro ISAPI o hacer que su código ASP/ASPX agregue el encabezado manualmente. Sin embargo, como se señala en el blog IEInternals, hemos determinado que hay bastantes formas diferentes de desencadenar el comportamiento erróneo, y desafortunadamente el reinicio previo al analizador debido a un conjunto de caracteres es solo uno de ellos. Se necesita una solución en el navegador para eliminar realmente este problema. – EricLaw

2

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx es la publicación actual sobre este tema.

Error 4k perdido: El artículo indica: "Al declarar el CHARSET de la página utilizando el encabezado HTTP Content-Type en lugar de especificarlo dentro de la página, puede eliminar una causa de reinicios del analizador". Eric Lawrence en un correo electrónico: "Desafortunadamente, otra causa conocida de reinicios del analizador es el uso de espacios de nombres XML, que parece que su sitio utiliza". Entonces, si usas XHTML, ¡puede ocurrir el problema 4K!

0

Tenemos el mismo problema. Estoy agregando:

 Response.ContentType = "text/html" 
     Response.Charset = "utf-8" 

a nuestra clase de página de base. Voy a informar sobre los resultados en breve.

+0

Sin suerte, todavía con el problema. – ChickenMilkBomb

0

FWIW Aquí están las estadísticas que obtuve de 1 mes de registros en LogParser.

12331 hits to ScriptResource & WebResource/183 errors

Desglosado por useragent información.Parece ser compatible con la teoría de solo IE8 (más agentes de usuario de "modo de compatibilidad").

 
cs-uri-stem   MSIEVersion TridentVersion COUNT 
/WebResource.axd  MSIE+8.0 Trident/4.0  100 
/ScriptResource.axd MSIE+8.0 Trident/4.0  36 
/WebResource.axd  MSIE+7.0 Trident/4.0  44 
/ScriptResource.axd MSIE+7.0 Trident/4.0  2 
/ScriptResource.axd NOT IE  NOT Trident  1 

El error solo IE8 no tiene ninguna cadena de consulta en absoluto, procedente de un navegador Firefox/3.5.3 (tiene que estar relacionado).

No tengo ningún META HTTP-EQUIV = "Tipo de contenido" en mis páginas. Aunque SÍ tengo esto para despedir a los usuarios que no son Javascript.

<noscript> 
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript"> 
</noscript>