javascript asp.net .net exception-handling ajax.net

javascript - Error ASP.NET Ajax: Sys.WebForms.PageRequestManagerParserErrorException



exception-handling ajax.net (14)

Resolví exactamente este mismo problema eliminando el Content-Type: forma la sección Custom HTTP Headers en la pestaña HTTP Headers en IIS . Esto estaba rompiendo la codificación de la página y de alguna manera afectó a Ajax en general.

El tipo de Content-Type que había configurado en IIS estaba configurando la codificación en ISO-8859-1 .

Mi sitio web me ha estado dando errores intermitentes al intentar realizar cualquier actividad de Ajax. El mensaje que recibo es

Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. Details: Error parsing near '' <!DOCTYPE html P''.

Entonces, obviamente, se trata de algún tipo de tiempo de espera del servidor o el servidor simplemente regresa a la basura destrozada. Esto generalmente, desafortunadamente no siempre, sucede

Probablemente hay un error en la publicación posterior. En este caso, puede ver los detalles sobre el error agregando un PostBackTrigger a su panel de actualización y haciendo referencia al botón que causa el problema:

<asp:updatepanel ID="updatepanel1" runat="server"> <Triggers> <asp:PostBackTrigger ControlID="button1" /> </Triggers> <ContentTemplate> </ContentTemplate> </asp:updatepanel>

Esto puede ser un poco raro, pero me solucionó el problema. No tenía ninguna de las razones comunes para el error, así que simplemente puse esta curita en la carga de la página:

if (Session.SessionID == "") { Page.Session.Add("SessionID", Session.SessionID); }

Problema: Sys.WebForms.PageRequestManagerParserErrorException ocurrirá al redirigir su página, digamos que haga clic en el botón dentro de UpdatePanel en aspxAjax.

Solución:

  1. Agregue un botón "Ir a" en su página aspx donde está usando el panel de actualización y agréguelo afuera del panel de Actualización

  2. En su código, asigne la Session["UseridJustregistered"]=Id de usuario registrada a la variable de sesión, por ejemplo, Session["UseridJustregistered"]=Id de DB o UsernameField

  3. Respose.Redirect("regSucces.aspx?urlid=''" + Session["UseridJustregistered"] + "''");

  4. Compruebe si la Session["UseridJustregistered"] es nula o no

Esta es la ANTIGUA forma Clásica ASP que puede resolver nuestro problema, para cuando Microsoft encuentre una solución, podemos abordarlo de esta manera.

Resolví este mismo problema al eliminar UpdatePanels anidados por error.

Me sucedió esto y ninguna de las causas en la lista en la respuesta aplicada. No encontré la raíz del problema hasta que deshabilité mi AJAX por completo. Descubrió que el código estaba guardando un objeto en el ViewState que contenía un objeto no serializable. Hice el objeto serializable y comenzó a funcionar de nuevo.

Hay una excelente entrada de blog por Eilon Lipton. Contiene muchos consejos sobre cómo evitar este error:

Sys.WebForms.PageRequestManagerParserErrorException: qué es y cómo evitarlo

Lee los comentarios también Hay un comentario de alguien con el mismo problema: " Lo resolví cambiando el tiempo de inactividad del servidor de mi grupo de aplicaciones en IIS . Solo era 5, así que lo incrementé y ahora funciona".

"El control UpdatePanel utiliza devoluciones de datos asincrónicas para controlar qué partes de la página se procesan. Lo hace usando un montón de JavaScript en el cliente y un montón de C # en el servidor.

Las devoluciones de datos asincrónicas son exactamente las mismas que las devoluciones de datos normales, excepto por una cosa importante: la representación. Las devoluciones de datos asincrónicas pasan por los mismos eventos de ciclos de vida que las páginas normales (esta es una pregunta que me hacen con frecuencia).

Solo en la fase de renderizado las cosas se ponen diferentes. Capturamos el renderizado de solo los Paneles de Actualización que nos interesan y lo enviamos al cliente usando un formato especial. Además, enviamos otros tipos de información, como el título de la página, los valores ocultos del formulario, el URL de la acción del formulario y las listas de scripts ".

Las razones más comunes para ese error:

  1. Llamadas a Response.Write ():
  2. Filtros de respuesta
  3. HttpModules
  4. El rastreo del servidor está habilitado
  5. Llamadas a Server.Transfer ()

Finalmente resolví mi variante de este mismo problema. Estaba intentando copiar / mover un valor seleccionado entre 2 listboxes en un formulario web. En mi caso, tuve que llamar específicamente a {listbox} .ClearSelection () antes de realizar la acción la segunda vez.

Entonces, obviamente, este mensaje de problema / error puede ocurrir por una multitud de razones.

El cambio del grupo de aplicaciones DESDE INTEGRADO a asp.net classic resolvió el problema para mí.

También recibí este error. La solución informada por "user1097991" la resolvió por un tiempo (estaba usando objetos no serializados en viewstate)

Pero luego el error volvió nuevamente, ahora de forma aleatoria. Después de buscar, obtuve la respuesta: viewview se estaba volviendo demasiado grande y se había truncado. Desactivo algunos viewstates en grillas y menús y el problema no se ha vuelto a mostrar.

Descubrí que mi problema estaba relacionado con la aparición de un carácter nulo en la unión de datos de un GridView. La duración esperada de la respuesta no coincidía con la longitud real del texto de respuesta que resultó en el error. Una vez que arreglé los datos en la base de datos, ya no recibí el error. La solución definitiva será desinfectar el texto que se procesa durante el evento RowDataBound.

Al mirar a través de la base de datos, no pude ver los datos incorrectos ya que SQL Server 2008 no muestra el texto si el carácter nul (Char (0)) está en la cadena. En el evento RowDataBound de mi GridView, agregué código para lanzar una excepción para cualquier texto que tuviera caracteres especiales. Así es como encontré el registro que contenía los caracteres nul.

tl; dr - Compruebe si hay caracteres nulos en el html representado.

Tenga en cuenta también que esto puede ser causado por una codificación html incorrecta de lo que puede estar procesando en la página mediante devoluciones de datos parciales.

Tenía exactamente el mismo error.

Para mí fue

<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Falta en la sección httpModules de web.config (aplicación .Net 3.5)

Este error parece estar relacionado con muchas cosas diferentes.

En nuestro caso, el problema fue causado por un proxy de reescritura en el camino. La reescritura modificó el contenido de la respuesta del panel de actualización. Pero esta respuesta también contiene el tamaño original. El mecanismo de reescritura no puede saber que pocos bytes de la respuesta en realidad contienen el tamaño de la respuesta original y también debe modificarse.

La respuesta del panel de actualización comienza así:

1|#||4|30502|updatePanel|pnlUpdate| ...

El 30502 es el tamaño original del contenido que se está actualizando. El motor de reescritura modifica la salida, pero el tamaño permanece inalterado => excepción de error del analizador.

No veo una forma de superar este problema desde el lado del cliente. Necesitaríamos saber exactamente cómo se modificó el contenido y de alguna manera cambiar el tamaño en la respuesta antes de que UpdatePanel ClientScript comience a procesarlo.