J'ai un client qui soumet une requête Web (POST) de données XML à un serveur. La tête du XML lit <?xml version="1.0" encoding="utf-16"?> mais les données sont vraiment utf-8. Nous essayons d'intercepter le flux existant (et tout le monde impliqué réalise cela, nous essayons de mettre en avant et en arrière donc s'il y a des temps d'arrêt nous pouvons au moins tamponner les demandes) mais IIS semble rejeter le XML parce que l'encodage réel ne correspond pas au codage indiqué.Comment un en-tête XML (codage) incorrect peut-il être modifié à la volée dans IIS avant d'être analysé par une classe WCF?
Si nous manuellement (en utilisant une chaîne comme notre valeur d'origine dans une application de test client) forcer le flux d'octets codé et définir la valeur d'encodage dans la chaîne à soit UTF-32 ou UTF-8 en C# et fourrer dans notre méthode WCF, cela fonctionne bien. Mais en envoyant en UTF-8 des valeurs codées avec un en-tête dans le fichier qui lit UTF-16, il bombarde out.
Enfin, et le plus exaspérant, je ne suis pas le principal développeur à ce sujet, je l'ai vu un total de 6 heures sur 4 jours, et je suis chargé de trouver un peu de magie poser environ. Quelqu'un a des idées?
Donc, mon problème est avec IIS ou ASP.NET, je le réalise. Je ne sais pas exactement quoi et où donner un coup de pied cette fichue chose, et je ne sais pas exactement quels détails me manque pour la question. Je l'ai fait dans le salon de chat avant de poster ici, et quelques détails supplémentaires ont été mis au jour, mais si vous avez des questions, je suis prêt à y répondre, comme je peux. Vous demandez juste ce que vous voulez voir, et je partagerai. Et je vais renoncer à aller de l'avant et poster beaucoup de code C# et web.config parce que, honnêtement, je ne sais pas quel est le meilleur point de départ pour aborder ce problème particulier.
Il n'y a donc aucun moyen de réparer l'en-tête sur le client?
Pas en ce moment. Je viens de passer 30 minutes sur un appel de soutien du groupe, et leur dev principal de ce projet est pour les 10 prochains jours, et notre groupe de vente a promis notre produit jusqu'à la fin de cette semaine
-t-il jeter un erreur qui pourrait être piégée?
Non. Le client signale une erreur 400. C'est la mesure de notre capacité à suivre ce chiot, dès maintenant. J'espère que quelqu'un ici avec plus de familiarité sur IIS fixe que pour moi;)
Je suis à la recherche soit
- une ASP.NET ou d'une solution IIS qui me permet de dire la entrée que je me fous de ce qu'il est écrit codage est, tyvm, je sais mieux, OU
- un moyen WCF d'intercepter le flux avant qu'il ne frappe mes méthodes de classe, puis réécrire la chaîne à la volée en examinant le
<?xml version="1.0" encoding="utf-16"?>sur cette demande particulière.
Est-ce qu'il lance une exception partout utile? Si c'est le cas, vous pourriez le piéger et continuer. – ChrisF
Excellente question @ChrisF ~ Non. Le mieux c'est de renvoyer un 400 au client. Je vais mettre à jour la question. – jcolebrand
Dites-nous encore pourquoi vous ne corrigez pas votre code pour arrêter de mentir sur l'encodage XML? –