2010-04-06 3 views
8

Dans les pages qui ont un état d'affichage qui couvre 10-15KB ce serait une valeur optimale pourQuelle est une valeur optimale pour maxPageStateFieldLength dans ASP.NET

<pages maxPageStateFieldLength="">

dans le web.config afin de réduire le risque de troncature potentielle conduisant à des erreurs de validation viewstate?

+0

avez-vous optimisé l'utilisation de ViewState? Peut-être pouvez-vous réduire la taille en la désactivant là où ce n'est pas nécessaire et vous n'aurez pas besoin d'utiliser maxPageStateFieldLength –

+0

À court de réécrire complètement le viewstate pour inclure la compression, oui. –

Répondre

1

Le maxPageStateFieldLength ne limite pas la taille de l'état d'affichage, il ne sera donc pas tronqué.

Ce qu'il fait est simplement de contrôler combien de l'état d'affichage sera placé dans un champ caché. Si l'état d'affichage est supérieur à la valeur maxPageStateFieldLength, l'état d'affichage sera simplement divisé en plusieurs champs masqués.

La valeur par défaut est -1, ce qui signifie que l'état d'affichage est placé dans un seul champ masqué, qui est normalement le plus optimal.

+2

Oui, c'est pourquoi j'ai demandé une valeur optimale que, je comprends ce qu'il fait. J'ai vu des nombres aussi bas que 40, 100 autres occurrences de 1000, je n'ai pas vraiment vu de justification pour aucun nombre car il semble que des sélections arbitraires qui ne sont même pas des puissances de 2. –

+0

@Chris: La seule raison que je vois pour l'utilisation de toute autre valeur que la valeur par défaut, c'est si vous avez besoin de limiter la taille des valeurs de champs pour une raison quelconque. Si vous avez ce besoin, la valeur la plus optimale serait la valeur la plus élevée que vous puissiez utiliser. – Guffa

+4

Si je connaissais ce nombre, je n'aurais pas posté cette question. La raison pour laquelle cette fonctionnalité a été ajoutée à ASP.NET en 2.0 est que les antivirus/routeurs/proxies/etc peuvent potentiellement tronquer un seul grand champ caché qui provoque alors correctement l'invalidité de pagestate. Puisqu'il s'agit d'un problème client qui n'est pas spécifiquement reproductible, c'est pourquoi je cherche un consensus sur ce qu'est exactement une valeur optimale pour ce qui n'est pas la valeur par défaut de -1. –

0

Je suis actuellement confronté à un problème où nous recevons des erreurs "HttpException due à Invalid Viewstate" pour les utilisateurs de Firefox uniquement. Je vois également "System.Web.HttpException: Une erreur s'est produite lors de la communication avec l'hôte distant.Le code d'erreur est 0x80070001" exceptions paired avec les viewstate. Je crois que firefox a peut-être une taille maximale sur (éventuellement) les champs de formulaire cachés - j'ai besoin de vérifier cela. Je cherche maintenant à tronquer le viewstate en utilisant maxPageStateFieldLength pour espérer résoudre (à court terme). La solution à plus long terme est de refactoriser la page aspx pour faire une requête de pagination pour la grille (au lieu de tirer toutes les lignes en une fois, ce qui n'est pas une bonne chose à faire).

À mon humble avis, vous devriez mettre dans un maximum qui est assez grand mais pas illimité. Je dirais que 1 Mo est un début.

+0

J'ai vu ce comportement avec l'état d'affichage qui est seulement dans la gamme 10-15KB, c'est pourquoi je supposais qu'une valeur de segment devrait être petite, probablement 512bytes ou quelque chose, mais même en essayant si bas je n'ai jamais vu ces les erreurs disparaissent. Cela m'a juste fait abandonner les webforms et déplacer tout nouveau développement vers MVC. –

+0

Merci pour l'article Chris. Et corriger cela n'a pas résolu le problème. J'ai vu des messages sur des serveurs proxy tronquant de grands champs cachés. Je me dirige également vers l'élimination de viewstate. C'est une douleur dans les fesses. Malheureusement, beaucoup de code hérité et de passer à MVC est une bataille difficile. Eh bien, on peut rêver. –

+0

Bonne chance avec l'élimination de viewstate Je ne pense pas que ce soit possible si vous utilisez presque n'importe quel type de contrôles, j'ai essayé cette route avec la version .NET4 censée rendre cela possible et jamais obtenu n'importe où. Pour passer à MVC, nous venons de suivre une transition décalée, car nous remanions toute fonctionnalité existante, ce qui nous permet de la retirer des anciens projets et de la déplacer. –

Questions connexes