Parámetros de Webresource.axd no válidos que se generan
https://stackoverflow.com/questions/461605
-
19-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Pregunta original:
Tenemos un error extraño con la generación de URL de WebResource.axd. (No parece estar relacionado con el bastante común " WebRsource.axd Padding no es válido y no se puede eliminar " problema).
Tenemos una página web ASP.NET que, cuando se crea, agrega una referencia de script a WebResource.axd.
En este caso, estamos viendo que el enlace WebResource.axd ocasionalmente se convierte en basura más allá de cierto punto, reemplazado por lo que parece JavaScript. Peor aún, el error de generación de URL parece ser inconsistente.
En nuestro caso, el enlace debería (y generalmente sí se ve ):
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
Todo bien y bien. Sin embargo, los usuarios registran errores ... y la URL a la que intentan acceder se ve (en un caso):
/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......
[el javascript codificado restante de ese enlace se ha eliminado como irrelevante]
Más extraño aún, obtuvimos algunos de estos en rápida sucesión del mismo usuario, que aparentemente estaba tratando de volver a cargar la página ... cada url un poco diferente.
/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>
En algunos casos, la basura está codificada en JavaScript, he visto partes de una url ... cadenas de parámetros completamente vacías ... No veo un patrón obvio.
Además, si fuera relevante, debe tenerse en cuenta que no creo que este WebResource sea otra cosa que un WebResource de stock que .NET incluye automáticamente cuando se incluyen ciertas características en una página ... en este caso, un validador de campo. Al observar el contenido del WebResource.axd real, se revela un conjunto de funciones Javascript de aspecto muy estándar que parecen diseñadas para manejar eventos genéricos .NET. No hay nada que hayamos creado.
¿Alguien ha visto algo como esto? (o mejor, ¿alguien ha entendido por qué sucedía esto y se le ocurrió una forma de eliminarlo?)
EDITAR 0: Alguna información adicional:
Elemento 1: en respuesta a una respuesta, nos aseguramos de que nuestros scripts estén encerrados con etiquetas CDATA, ya que nuestro doctype es xhtml de transición:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Desafortunadamente, aunque teníamos muchas esperanzas, no parece haber resuelto el problema. Hemos notado esto más a menudo con IE 8 como navegador, lo que daría cierta credibilidad a la idea de que esto está relacionado con el navegador ... tal vez la forma en que el navegador analiza la transmisión ... pero por qué obtendríamos respuestas sutilmente diferentes en intentos posteriores me desconcierta.
Artículo 2: Resulta que las secciones omitidas parecen ser bloques de tamaño bastante regular. Alguien informó que estaba viendo que faltaban 1k o 4k bloques, y yo (hasta ahora ... solo he visto dos casos hasta ahora) estaría de acuerdo (a los dos les faltaban 4096 bytes de datos).
Solución 7
Microsoft eventualmente solucionó esto:
http: // blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
Otros consejos
según esta publicación:
Parece que el problema está causado por la forma en que los navegadores procesan las páginas de manera diferente cuando no se especifica el doctype.
Aquí hay otra publicación interesante que encontré sobre este tema, aunque todavía no es la solución:
http://blog.aproductofsociety.org/?p=11
en la página anterior tiene " Response.Cache.SetNoStore () " como una posible solución en los comentarios, intentaré esto a continuación para ver si ayuda.
Microsoft ha respondido a este problema:
Nota es un error en Internet Explorer 8. 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 utilizará correctamente en ese momento.
- = Circunstancias = - La solicitud falsa parece ocurrir solo en ciertas situaciones de tiempo, solo cuando una etiqueta META HTTP-EQUIV que contiene un tipo de contenido con una directiva CHARSET aparece en el documento, y solo cuando una URL de JavaScript SRC abarca el byte 4096 del cuerpo de respuesta HTTP.
- = Solución alternativa - Por lo tanto, actualmente creemos que este problema puede mitigarse declarando el CHARSET de la página utilizando el encabezado HTTP Content-Type en lugar de especificarlo dentro de la página.
Entonces, en lugar de poner
[META HTTP-EQUIV = " Tipo de contenido " CONTENIDO = " texto / html; charset = utf-8 "]
En su etiqueta de encabezado, en su lugar, envíe el siguiente encabezado de respuesta HTTP:
Tipo de contenido: texto / 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, el uso del encabezado HTTP ayuda a mitigar ciertos vectores de ataque XSS.
NOTA: Ha habido informes de que este problema aún ocurre cuando META HTTP-EQUIV no está en la página. Actualizaremos este comentario cuando tengamos más investigación. Publicado por Microsoft el 30/06/2009 a las 12:25 p. M.
Soy del equipo de ASP.NET, estamos buscando un cliente dispuesto a trabajar con nosotros para investigar este problema. Si alguien puede reproducir el problema de manera confiable al solicitar sus propias páginas y verificar los registros, y está dispuesto a trabajar con nuestro grupo de soporte, responda o envíeme un mensaje directo. Gracias!
¿Con qué versión de .NET está compilando? ¿Qué sucede si cambia su compilación para compilar para una versión anterior o anterior? (no estoy seguro si esto haría algo pero vale la pena intentarlo)
Si todavía está sucediendo, creo que debería publicar un error al respecto en Microsoft Connect . Deberían volver a usted bastante rápido.
¿Tiene algún HttpHandlers o Módulos que estén registrados en la configuración web que modifiquen el HTML representado antes de enviarlo al usuario?
Estos a menudo pueden ser:
- Minifiying JS y CSS
- Asegúrese de que HTML sea válido
Podría valer la pena echarle un vistazo.
Esta es una publicación antigua ... pero me encontré con una búsqueda en Google y me recordó esto ...
http: //www.troyhunt. com / 2010/09 / fear-incertidumbre-y-y-relleno-oracle.html
¿Podría haber estado relacionado?
