internet-explorer - sistemas - paginacion y segmentacion

IE 8 dejando caer las páginas de memoria?

Question

Esta pregunta es un spin-off / evolución de esta pregunta . (Esa pregunta se marcó como resuelta porque puse una recompensa en ella y se resolvió automáticamente, pero en realidad nunca fue respondida).

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 simple ejemplo ... si tenemos una página que se ve así:

<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 solicitar la url: "myValidLiORE% 20STUFF% 20LATER".

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

Lamentablemente, no podemos replicar este error a pedido, aunque lo vemos venir de los 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, y esos errores solían ocurrir cuando ocurría la corrupción. 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 manera 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) en algunas condiciones.

Sin embargo, estoy un poco preocupado por esta teoría, ya que aparentemente algunas personas han informado haber visto esto "ocasionalmente" con IE 6 o FF 3 ... estos tienden a ser atípicos, y podrían ser solo problemas diferentes con síntomas similares, pero si en realidad es 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 un paquete de servicio relativamente reciente en el servidor está causando problemas con los datos que se están sirviendo 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.

Entonces las preguntas, que con suerte eventualmente tendrán respuestas:

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

Answer 1

** Editar 4/1/10: ** Actualización: El error 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 ahora, 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 solicitud espuria parece producirse solo en determinadas situaciones de temporización, solo cuando el pre-analizador está obligado a reiniciarse (como cuando una etiqueta META HTTP-EQUIV contiene un tipo de contenido con una directiva CHARSET aparece en el documento) y solo cuando un JavaScript SRC URL abarca el 4096o byte del cuerpo de respuesta HTTP.

- = Solución temporal - -

Actualmente creemos que este problema generalmente puede mitigarse declarando el CHARSET de la página usando el encabezado HTTP Content-Type en lugar de especificarlo dentro de la página.

Entonces, en lugar de poner

[META HTTP-EQUIV = "Contenido-Tipo" CONTENT = "text / html; charset = utf-8"]

En su etiqueta principal, en su lugar, envíe el siguiente encabezado de respuesta HTTP:

Content-Type: text / html; charset = utf-8

Tenga en cuenta que la especificación del juego de caracteres en el encabezado HTTP da como resultado un rendimiento mejorado en todos los navegadores, porque los analizadores del navegador no necesitan reiniciar el análisis desde el principio al encontrar la declaración del conjunto de caracteres. Además, usar el encabezado HTTP ayuda a mitigar ciertos vectores de ataque XSS.

Answer 2

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 información de useragent. 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 único error que no es IE8 no tiene ninguna cadena de consulta, proveniente de un navegador Firefox / 3.5.3 (tiene que estar sin relación).

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

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

Answer 3

Tenemos el mismo problema. Estoy agregando:

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

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

Answer 4

blogs.msdn.com/ieinternals/archive/2009/07/27/… es la publicación actual sobre este tema.

The Missing 4k Bug: el artículo dice: "Al declarar el CHARSET de la página usando el encabezado HTTP Content-Type en lugar de especificarlo dentro de la página, puede eliminar una causa de los 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!