2008-11-14 9 views
23

Meine Website hat mich intermittierende Fehler bei dem Versuch, irgendwelche Ajax Aktivitäten durchzuführen. Die Nachricht, die ich bekomme, istASP.NET Ajax Fehler: Sys.WebForms.PageRequestManagerParserErrorException

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'. 

So ist es offensichtlich eine Art von Server-Timeout oder der Server ist nur zurückgekehrt vermüllten Müll. Dies passiert im Allgemeinen leider nicht immer,

+0

@Phil - Ich bemerke, dass Sie splattne Antwort richtig markiert, aber Sie sagten in einem Kommentar darunter, dass keiner von ihnen angewendet. Ich habe das gleiche Problem, und keine der "Gründe" gilt auch für mich. Was war die Lösung, die Sie schließlich gefunden haben? – AdamBT

+3

@AdamBT - Entschuldigung, ich wurde im Februar von diesem Job entlassen und kann mich nicht erinnern, was wir getan haben. Entschuldigung, ich habe deinen Kommentar so lange verpasst. –

+0

http://niharstechnicalfunda.blogspot.in/2012/03/syswebformspagerequestmanagerparsererro.html – Niks

Antwort

22

Es gibt einen ausgezeichneten Blog-Eintrag von Eilon Lipton. Es enthält von vielen Tipps, wie man diesen Fehler zu vermeiden:

Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it

auch die Kommentare lesen. Es gibt einen Kommentar von jemandem mit dem gleichen Problem: "Ich löste es wechseln Server Leerlaufzeit meines App-Pool auf IIS. Es war nur 5, also habe ich es inkrementiert und funktioniert jetzt."

„Die Update Steuerung verwendet asynchrones Postbacks zu steuern, welche Teile der Seite gerendert bekommen. Es tut dies auf dem Server eine ganze Reihe von JavaScript auf dem Client und eine ganze Reihe von C#.

asynchrone Postbacks sind genau die gleichen wie regelmäßige Postbacks mit Ausnahme eine wichtige Sache. die Wiedergabe Asynchronous Postbacks gehen durch die gleichen Lebenszyklen Ereignisse als reguläre Seiten (dies ist eine Frage, die ich gefragt werde oft)

Nur an der. Renderphase machen die Dinge anders Achten Sie darauf, dass nur die von uns betreuten UpdatePanels gerendert werden, und senden Sie sie in einem speziellen Format an den Client. Darüber hinaus senden wir einige andere Informationen, wie der Seitentitel, versteckte Formularwerte aus, die Form Aktion URL und Listen von Skripten „

Die häufigsten Gründe für diesen Fehler.

  1. Anrufe zu Response.Write():
  2. Response-Filter
  3. Httpmodules
  4. Server-Trace
  5. Cal aktiviert ls Server.Transfer()
+0

Ich habe den Artikel gelesen - keiner von diesen trifft zu. Der Fehler könnte tatsächlich das Update-Panel auf der Masterseite sein. Vielen Dank! –

+0

Ein Benutzer unserer Software sieht einen sehr ähnlichen Fehler. Ich frage mich, ob jemals eine Lösung für dieses Problem gefunden wurde? –

+0

Ich würde der Frage einen Kommentar hinzufügen. So wird der Benutzer aufgefordert, das nächste Mal, wenn er sich anmeldet. – splattne

1

Ich löste dieses genau die gleiche Problem der Content-Type: Form den Custom HTTP Headers Abschnitt in den HTTP Headers Registerkarte in IIS entfernen. Das hat die Verschlüsselung der Seite durchbrochen und irgendwie hat es Ajax im Allgemeinen beeinflusst.

Die Content-Type Ich hatte in IIS konfiguriert wurde, legte die Codierung auf ISO-8859-1.

1

Dies kann ein wenig hacky sein, aber es löste das Problem für mich. Ich habe nicht eine der häufigsten Ursachen für den Fehler, so dass ich nur in diesem Band-Aid in der Seite zu laden setzen:

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

Problem: Sys.WebForms.PageRequestManagerParserErrorException wird auftreten, wenn Sie Ihre Seite umleiten, sagen wir, klicken Sie in UpdatePanel in aspxAjax klicken.

Lösung:

  1. hinzufügen "GoTo" Knopf in Ihrer aspx Seite, wo Update-Panel mit und fügen Sie es außerhalb Panel-Update

  2. In Ihrem Code zuweisen ur nur registrierte Benutzer-ID zu Session-Variablen sagen, Session["UseridJustregistered"]=Id von DB oder Benutzernameauszuwählen

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

  4. Prüfen Sie, ob Session["UseridJustregistered"] null ist oder nicht

Das ist alte klassische ASP Art und Weise, die unser Problem lösen können, durch die Zeit Microsoft eine Lösung finden wir es auf diese Weise angehen können.

9

Wahrscheinlich gibt es einen Fehler beim Post zurück. In diesem Fall können Sie die Details über den Fehler anzeigen, indem Sie eine Postback zu Ihrem Update Hinzufügen und Verweisen auf die Schaltfläche, das das Problem verursacht:

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

     </ContentTemplate> 
    </asp:updatepanel> 
+0

Dank Man :) Es funktioniert – kbvishnu

+0

Vielen Dank. Ich habe versucht für 1 ganzen Tag, aber Ihre Antwort half mir viel :) –

1

Ich löste das gleiche Problem durch versehentlich verschachteltes Update entfernen.

4

Ich hatte dies mit mir geschehen und keine der Ursachen auf der Liste in der Antwort angewendet. Ich habe die Ursache des Problems erst gefunden, als ich meinen AJAX vollständig deaktiviert habe. Es wurde festgestellt, dass der Code ein Objekt in ViewState speicherte, das ein unserialisierbares Objekt enthielt. Ich habe das Objekt serialisierbar gemacht und es hat wieder angefangen zu arbeiten.

+1

Das war mein Problem. – bdwakefield

1

Ich habe endlich meine Variante des gleichen Problems gelöst. Ich habe versucht, einen ausgewählten Wert zwischen 2 Listenfeldern in einem Webformular zu kopieren/zu verschieben. In meinem Fall musste ich {listbox} .ClearSelection() aufrufen, bevor ich die Aktion zum zweiten Mal ausführte.

So offensichtlich kann diese Problem/Fehlermeldung aus einer Vielzahl von Gründen auftreten.

1

Änderung des App-Pools VON INTEGRATED zu asp.net classic löste das Problem für mich.

0

Ich habe auch diesen Fehler. Die Lösung, die von "user1097991" gemeldet wurde, löste es für eine Weile (ich verwendete nicht-serialisierte Objekte auf Viewstate)

Aber später kam der Fehler wieder, jetzt in einer zufälligen Art und Weise. Nach einiger Suche bekam ich die Antwort: Der Viewstatus wurde zu groß und wurde abgeschnitten. Ich deaktiviere einige Viewstates in Grids und Menüs und das Problem wurde nicht erneut angezeigt.

0

Ich stellte fest, dass mein Problem damit zusammenhing, dass ein Null-Zeichen in der Datenbindung einer GridView gerendert wurde. Die erwartete Länge der Antwort stimmte nicht mit der tatsächlichen Länge des Antworttexts überein, der dazu führte, dass der Fehler ausgelöst wurde. Sobald ich die Daten in der Datenbank repariert habe, habe ich den Fehler nicht mehr erhalten. Die ultimative Lösung besteht darin, den Text, der während des RowDataBound-Ereignisses gerendert wird, zu bereinigen.

Beim Durchsuchen der Datenbank konnte ich die fehlerhaften Daten nicht sehen, da SQL Server 2008 den Text nicht anzeigt, wenn das Nullzeichen (Char (0)) in der Zeichenfolge enthalten ist. Im RowDataBound-Ereignis meiner GridView habe ich Code hinzugefügt, um eine Ausnahme für jeden Text zu erzeugen, der Sonderzeichen enthält. So fand ich den Datensatz, der die Null-Zeichen enthielt.

tl; dr - Prüfen Sie, ob im gerenderten HTML-Code keine Zeichen enthalten sind.

0

Bitte beachten Sie auch, dass dies durch nicht korrekt HTML-Codierung verursacht werden kann, was Sie auf der Seite durch teilweise Postbacks rendern können.

0

Ich hatte genau den gleichen Fehler.

Für mich war es

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

im Httpmodules Abschnitt von web.config Missing (Net 3.5 app)

Dieser Fehler scheint zu viele verschiedene Dinge in Beziehung gesetzt werden zu können.

+0

Welcher Abschnitt der web.config? – JoshYates1980

+0

Hallo. Wie gesagt, es ist . – AFract

1

In unserem Fall wurde das Problem durch einen Rewriting-Proxy auf dem Weg verursacht. Das Neuschreiben modifizierte den Inhalt der Antwort des Update-Panels. Aber diese Antwort enthält auch Originalgröße. Der Neuschreibmechanismus kann nicht wissen, dass wenige Bytes der Antwort tatsächlich die ursprüngliche Antwortgröße enthalten, und sie sollte ebenfalls geändert werden.

Die Update-Panel Antwort beginnt wie folgt aus:

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

Die 30502 ursprüngliche Größe des Inhalts ist, die aktualisiert wird. Rewriting Engine ändert die Ausgabe, aber die Größe bleibt unverändert => Parser Fehler Ausnahme.

Ich sehe keinen Weg, wie dieses Problem von der Client-Seite zu überwinden. Wir müssten wissen, wie genau der Inhalt geändert wurde, und dann irgendwie die Größe in der Antwort ändern, bevor UpdatePanel ClientScript mit der Verarbeitung beginnt.

+0

Hallo mirva! Haben Sie eine Lösung für Ihr Problem gefunden? – Franki1986

+0

Hallo Franki. Leider nicht. Wir haben das Problem dem Anbieter des Proxys gemeldet, aber mir ist keine Lösung bekannt. – mivra

+0

Danke für die Antwort. Ich musste jedes updatepanel mit einem devexpress Callbackpanel ersetzen. – Franki1986