asp.net webresource.axd invalid-url

asp.net - Los parámetros de Webresource.axd no válidos se están generando



invalid-url (7)

Pregunta Original:

Tenemos un error extraño con la generación de URL WebResource.axd. (No parece estar relacionado con el problema bastante común de "WebRsource.axd Padding no es válido y no se puede eliminar").

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, la falla de generación de URL parece ser inconsistente.

En nuestro caso, el enlace debe (y generalmente se ve):

/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315

Todo bien y bien Sin embargo, estamos recibiendo errores registrados por los usuarios ... y la url a la que intentan acceder se parece (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 eliminó como irrelevante]

Aún más extraño, obtuvimos algunos de estos en rápida sucesión del mismo usuario, que al parecer estaba tratando de volver a cargar la página ... cada url ligeramente 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.

Por otro lado, en caso de ser relevante, debe tenerse en cuenta que no creo que este WebResource sea otro que un stock WebSource que sea incluido automáticamente por .NET cuando se incluyen ciertas características en una página ... en este caso , un validador de campo. Al mirar los contenidos del WebResource.axd real se revela un conjunto de funciones de Javascript que parecen muy estándares y parecen estar diseñados para manejar eventos .NET genéricos. No nada de lo que hemos creado.

¿Alguien ha visto algo como esto? (o mejor, ¿alguien ha entendido por qué sucedía esto y ha encontrado una forma de eliminarlo?)

EDIT 0: Alguna información adicional:

Ítem ​​1: En respuesta a una respuesta, nos aseguramos de que nuestros scripts estén encerrados con etiquetas CDATA, ya que nuestro doctype es xhtml transitional:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Desafortunadamente, aunque teníamos grandes esperanzas, no parece haber resuelto el problema. Hemos notado esto más a menudo con IE 8 como navegador, lo que daría cierto crédito 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.

Ítem ​​2: Resulta que las secciones omitidas parecen ser bloques de tamaño bastante regular. Alguien informó que estaba viendo la falta de 1k o 4k bloques, y yo (hasta ahora ... solo he visto dos casos hasta ahora) estaría de acuerdo (los dos carecían de 4096 bytes de datos).

según esta publicación:

http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Parece que el problema se debe a 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 aún 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 me ayuda.

¿En qué versión de .NET estás compilando? ¿Qué sucede si cambia su compilación para compilar para una versión anterior o más nueva? (no estoy seguro de si esto haría cualquier cosa, pero vale la pena intentarlo)

Si todavía está sucediendo, creo que deberías publicar un error al respecto en Microsoft Connect . Deben volver a ti muy rápido.

¿Tienes HttpHandlers o Módulos que están registrados en la configuración web que modifican el HTML renderizado antes de enviarlo al usuario?

Estos a menudo pueden ser:

  • Minifiying JS y CSS
  • Asegúrese de que HTML sea válido

Puede valer la pena mirar.

Soy del equipo de ASP.NET. Buscamos un cliente dispuesto a trabajar con nosotros para investigar este tema. Si alguien puede reproducir el problema de manera confiable solicitando sus propias páginas y revisando los registros, y está dispuesto a trabajar con nuestro grupo de soporte, responda o envíeme un mensaje directo. ¡Gracias!

Microsoft ha respondido a este problema:

La 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 usará correctamente en ese momento.

- = Circunstancias = - La solicitud espuria parece ocurrir solo en ciertas situaciones de temporización, solo cuando aparece una etiqueta META HTTP-EQUIV que contiene un tipo de contenido con una directiva CHARSET en el documento, y solo cuando una URL SRC de JavaScript abarca la 4096ª byte del cuerpo de respuesta HTTP.

- = Solución temporal - Por lo tanto, actualmente creemos que este problema se puede mitigar 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 = "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.

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/6/2009 a las 12:25 p.m.