2009-05-07 8 views
27

Si un service WCF renvoie un tableau d'octets dans son message de réponse, il est possible que les données dépassent la longueur par défaut de 16384 octets. Lorsque cela se produit, l'exception sera quelque chose commeParamètres WCF readerQuotas - inconvénients?

Le quota de longueur maximale de la matrice (16384) a été dépassée lors de la lecture des données XML . Ce quota peut être augmenté de en modifiant la propriété MaxArrayLength sur l'objet XmlDictionaryReaderQuotas utilisé lors de la création du lecteur XML .

Tous les conseils que je l'ai vu sur le web est juste d'augmenter les paramètres de l'élément <readerQuotas> à leur maximum, donc quelque chose comme

<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
       maxArrayLength="2147483647" maxBytesPerRead="2147483647" 
       maxNameTableCharCount="2147483647" /> 

sur le serveur, et même sur le client.

Je voudrais connaître les inconvénients de cette approche, en particulier si la taille de la matrice d'octets ne peut être qu'occasionnellement très grande. Est-ce que les paramètres ci-dessus font que WCF déclare un énorme tableau pour chaque requête? Devez-vous limiter la taille maximale des données retournées, ou pouvez-vous simplement spécifier un tampon de taille raisonnable et faire en sorte que WCF continue jusqu'à ce que toutes les données soient lues?

Merci!

Répondre

33

Le principal inconvénient est une vulnérabilité potentielle aux attaques - par ex. une source malveillante peut maintenant inonder votre serveur Web avec un message d'une taille allant jusqu'à 2 Go et potentiellement l'abattre. Bien sûr, autoriser des messages de 2 Go met également votre serveur à rude épreuve en termes de consommation de mémoire, puisque ces messages doivent être entièrement assemblés en mémoire (sauf si vous utilisez des protocoles de streaming dans WCF). Si 10 clients vous envoient des messages de 2 Go, vous aurez besoin de beaucoup de RAM sur votre serveur! :-)

À part ça, je ne vois pas de vrais problèmes.

Marc

+0

Ok, donc ne les paramètres de la configuration du serveur juste sur les messages de demande, et les paramètres de la configuration client affectent les messages de réponse? Si j'ai un service qui prend un petit message de demande mais pourrait renvoyer une réponse importante, dois-je apporter des modifications à la configuration du serveur, ou le laisser aux clients? Existe-t-il un moyen de modifier la configuration du serveur de sorte que lorsqu'un client crée une référence de service, il sera automatiquement configuré pour les grandes réponses? Merci! –

+0

Comment cette "grande réponse" est-elle structurée? Est-ce essentiellement un fichier que vous retournez? Si c'est le cas, je vérifierais le streaming pour une réponse basée sur les flux. Si je comprends bien, le paramètre du serveur affecte à la fois les demandes entrantes, ainsi que les réponses sortantes, donc si vous définissez la taille du message trop petite, une réponse importante ne sera pas possible (vous êtes en train de dimensionner un tampon sur le serveur utilisé pour les demandes et les réponses). –

8

Il y a un article sur MSDN qui explique les différentes considérations de sécurité, vous devez penser à ces valeurs lors de la configuration. Certaines attaques par déni de service sont celles qui dévorent votre mémoire et certaines d'entre elles (telles que MaxDepth n'étant pas définies correctement) peuvent provoquer des StackOverflowExceptions fatales qui pourraient faire tomber votre serveur en une seule requête.

http://msdn.microsoft.com/en-us/library/ms733135.aspx

Questions connexes