Problème erratique de Viewstate dans une application .NET
Il semble que j'obtienne de temps en temps un "état de vue non valide" dans l'observateur d'événements pour mon application ASP.NET .
La plupart d'entre eux (95%) semblent faire référence à ScriptResource.axd (l'application utilise la bibliothèque ASP.NET AJAX ). Il n'y a aucun moyen de supprimer la bibliothèque Ajax , car Ajax est utilisé partout ..
Comment puis-je réduire ces erreurs? Je reçois environ 100 à 200 erreurs par jour et je ne sais pas comment les corriger! Ils proviennent de différents navigateurs, IP différentes et emplacements géographiques différents.
Il est difficile pour moi de reproduire le problème car il m'est à peine arrivé, il ne m'est arrivé que 3-4 fois à l'improviste.
Erreur:
Process information:
Process ID: 4004
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Exception information:
Exception type: HttpException
Exception message: Invalid viewstate.
Request information:
Request URL: http://domainnamehere/ScriptResource.axd?d=W1R6x9VzZ2C9SKnIkOmX9VRLhSjJ3nOF1GSQvPwKS3html
Request path: /ScriptResource.axd
User Host address: 124.177.170.75
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE
Thread information:
Thread ID: 1
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
at System.Web.UI.Page.DecryptString(String s)
at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)
at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection queryString, VirtualFileReader fileReader)
at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)
at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Custom event details:
For more information, see Help and Support Center at http://go.Microsoft.com/fwlink/events.asp.
Je reçois également cette erreur de temps en temps dans mon code .NET qui se produit en même temps et qui pourrait être lié:
Exception raised in GLOBAL.ASAX.Application_Error(): 'Padding is invalid and cannot be removed.' at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
Cela semble être le même problème IE8 que de nombreuses personnes ont rencontré. Ce qui semble se produire, c'est qu'en quelque sorte IE8 (en mode de rendu IE8 et en mode de compatibilité IE7) perdra 4096 octets du milieu du document HTML et ces données manquantes provoquent cette exception (vous voyez généralement cela dans un appel ScriptResource ou WebResource) .
Voici un rapport de bogue Microsoft sur le problème: https://connect.Microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997
Il existe également de nombreux messages sur le forum, le blog, etc. sur ce sujet:
- Paramètres Webresource.axd non valides générés
- IE 8 supprimant des pages mémoire?
- http://forums.asp.net/t/1373410.aspx?PageIndex=1
- http://forums.asp.net/p/1409964/3085329.aspx
Microsoft a répondu à ce problème:
Remarque est un bogue dans Internet Explorer 8. L'équipe d'Internet Explorer a étudié ce problème.
Impact : Jusqu'à présent, nous pensons que le problème n'a aucun impact sur l'expérience de l'utilisateur final avec l'application Web; le seul effet négatif est les demandes parasites/malformées envoyées par le moteur de téléchargement spéculatif JavaScript. Lorsque le script est réellement nécessaire à l'analyseur, il sera correctement téléchargé et utilisé à ce moment-là.
Circonstances : la demande parasite semble se produire uniquement dans certaines situations de synchronisation, uniquement lorsqu'une balise META HTTP-EQUIV contenant un type de contenu avec une directive CHARSET apparaît dans le document, et uniquement lorsqu'une URL JavaScript SRC couvre le 4096e octet du corps de réponse HTTP.
Solution: Par conséquent, nous pensons actuellement que ce problème peut être atténué en déclarant le CHARSET de la page à l'aide de l'en-tête HTTP Content-Type plutôt que de le spécifier dans le page.
Donc, plutôt que de mettre
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
Dans votre balise head, envoyez plutôt l'en-tête de réponse HTTP suivant:
Content-Type: text/html; charset=utf-8
Notez que la spécification du jeu de caractères dans l'en-tête HTTP améliore les performances dans tous les navigateurs, car les analyseurs du navigateur n'ont pas besoin de redémarrer l'analyse depuis le début lorsqu'ils rencontrent la déclaration de jeu de caractères. De plus, l'utilisation de l'en-tête HTTP permet d'atténuer certains vecteurs d'attaque XSS.
Remarque: il a été signalé que ce problème se produit toujours lorsque le META HTTP-EQUIV n'est pas sur la page. Nous mettrons à jour ce commentaire lorsque nous aurons plus d'enquête.
Publié par Microsoft le 30/06/2009 à 12h25.
Edit: Je vois toujours cette exception de temps en temps, mais ce bogue est signalé comme étant corrigé: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader- fixed.aspx
Je suppose que vous utilisez ASP.NET AJAX. J'ai le même problème. Sporadiquement, je trouverais cette exception dans mon journal des événements et le chemin demandé est TOUJOURS ScriptResource.axd.
L'utilisation de validationKey et decryptionKey fixes dans machineKey n'a pas résolu le problème pour moi.
Sur la base de ce que j'ai pu recueillir, j'ai tendance à croire que cette erreur n'a rien à voir avec le ViewState que ce soit; ma théorie est que pour une raison quelconque, certains UA gâchent en quelque sorte le paramètre "d" de ScriptResource.axd. Le problème est facilement reproductible en demandant manuellement le chemin d'accès incriminé. Cela donne une exception "Invalid ViewState", même si ViewState ne s'applique même pas ici.
En fouillant dans mes journaux, j'ai trouvé par exemple:
Cette demande est servie OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsd6r4E3B1
Cette demande légèrement différente est également servie OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJsACHwQQ6A6
Cette demande échoue avec une réponse 500 et l'exception ViewState non valide: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 products $ ctl00 $ AddToCart1 $ id
Si vous regardez attentivement, les premiers caractères des trois requêtes sont les mêmes, mais les derniers caractères de la dernière requête (en gras) sont clairement l'ID de contrôle "produits $ ctl00 $ AddToCart1 $ id" (j'ai un contrôle nommé produits et AddToCart). Je ne sais pas comment cet ID est arrivé, mais dans mon cas, c'est ce qui cause toutes ces exceptions ViewState non valides.
Je ne sais pas si c'est le même cas que l'OP ou non, mais je remarque que l'URL de demande de Martin se termine par "html", ce qui est un peu une coïncidence pour un paramètre qui est censé être une clé ...
J'ai déjà mal à la tête grâce à ce problème. Et jusqu'à présent, le message le plus perspicace que j'ai rencontré est celui-ci http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
Des idées?
Les problèmes de Viewstate sont ennuyeux et frustrants - j'ai remarqué que certaines personnes ont parlé de problèmes de Viewstate dans ce fil. Voici donc quelques suggestions que vous pouvez consulter dans l'ordre.
Je ferais déjà écho à ce que Freddy Rios a déjà dit dans le fil. Assurez-vous d'avoir codé en dur la clé machine. Cela résoudra la grande majorité de ces problèmes. L'important à propos du lien ScriptResource est qu'il doit avoir un paramètre d et un paramètre t dans la chaîne de requête. Si ce n'est pas le cas, quelque chose d'autre ne va pas!
Ne laissez pas l'utilisateur publier jusqu'à ce que vous ayez terminé. Vous pourriez probablement le faire avec javascript et un peu de css. De mémoire, je pense qu'il existe un moyen de le faire avec une balise META mais cela pourrait être IE uniquement.
Je voudrais rincer la réponse au début. Je pense qu'après le gestionnaire de script serait le meilleur. Mais vous devrez peut-être expérimenter un peu.
Si votre état de vue semble gonflé, activez la compression GZip dans IIS.
Si votre état de vue est devenu vraiment gonflé et que vous ne pouvez pas activer la compression GZip/ou si cela a un effet secondaire indésirable. Ensuite, vous pouvez compresser et décompresser l'état d'affichage. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx
Si cela vous laisse encore avec un état de vue gonflé, vous pouvez envisager de stocker le point de vue localement. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ est un bon point de départ.
Je pense que vous devez utiliser dans la page aspx:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
Cela résout mon problème
J'ai vu des problèmes comme celui-ci lorsque le Viewstate est trop grand. Je l'ai vu se produire en raison du problème décrit par Freddy.
Je n'aime généralement pas l'idée d'utiliser Viewstate. Pouvez-vous désactiver complètement Viewstate?
J'ai aussi ce problème, et j'ai essayé tout ce qui est mentionné dans tous les blogs que j'ai trouvés (clé fixe de la machine, taille de l'état d'affichage, etc.). 99% du temps, l'erreur est enregistrée sur les demandes à ScriptResource.axd. J'utilise .net 3.5 SP1, sur le serveur Win 2003. L'application est hébergée sur deux serveurs identiques parallèles, équilibrés 50/50. Chaque serveur possède la même clé machine.
Normalement, cette erreur ne me préoccupe pas beaucoup, cependant, sur une période de 3 mois, la tendance sur l'occurrence a augmenté.
Est-ce que quelqu'un pense que cette erreur est liée au fait que Viewstate n'est pas UrlEncoded/HtmlEncoded ou UrlDecoded correctement. Il existe peut-être un sous-ensemble de caractères dans l'état d'affichage que certains navigateurs remplacent par une valeur codée. Je ne sais pas si cela a même du sens ..
Utilisez une clé machine fixe (même lorsque vous utilisez un seul serveur).
Le problème se produit lorsque vous utilisez la configuration automatique de la clé machine, vous en obtenez une nouvelle à chaque fois que le domaine d'application est recyclé. Cela affecte la validation de l'état d'affichage, le déchiffrement des chaînes de requête des ressources dynamiques et les tickets d'authentification [insérer d'autres utilisations de la clé machine].
Je viens de limiter ce problème à un utilisateur avec l'antivirus Trend Micro et les erreurs ont juste commencé à se produire après avoir mis à jour son logiciel micro Trend le 21/05/2009. Aucune erreur avant cette date.
Le problème semble être le téléchargeur d'anticipation dans IE8.
Il semble n'affecter IE8 que dans un ensemble de circonstances assez obscures. L'une des raisons pour lesquelles cela peut passer inaperçu est qu'un morceau de données de 4 000 ajoutées à une URL est souvent rejeté par le serveur. Une des choses qui semble la rendre plus probable est une connexion réseau lente. Quelqu'un dans l'une des ressources ci-dessous a noté qu'il n'avait le problème qu'avec ses clients en Nouvelle-Zélande.
Beaucoup de gens expliquent deux problèmes distincts, dont l'un est décrit dans la question ci-dessus (URL malformées envoyées au serveur):
Article expliquant que le téléchargeur d'anticipation est corrigé:
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
KB980182 - Mise à jour cumulative dans laquelle le problème est résolu:
http://support.Microsoft.com/kb/980182
REMARQUE: Étant donné que le script est automatiquement re-téléchargé s'il ne peut pas être récupéré par le téléchargeur d'anticipation, il devrait être possible de revenir à l'ancien mode de validation dans lequel la validité des fichiers .axd n'a pas été vérifiée et supprime les symptômes du problème:
<httpRuntime requestValidationMode="2.0" />
Utilisez-vous un système d'exploitation non anglais?
Pour certaines raisons, le nom de compte "NT Authority\Network Service" a été localisé dans d'autres langues.
Malheureusement, de nombreux programmes ont le nom de compte codé en dur au nom anglais, et ne trouveront pas le service réseau lors de l'exécution sur des versions étrangères de Windows, conduisant à toutes sortes d'erreurs géniales dans le journal des événements.