WebServices schlagen fehl, weil (400) ungültige Anforderung wegen Sonderzeichen

Question

Unter Verwendung von Visual Studio 2008 richte ich einen Client ein, der Webdienste verwendet. Es hat nichts mit Puffergrößen zu tun (da dies eine typische Antwort ist, wurden alle geeigneten Größen erhöht).

Ich habe eine Liste als Parameter der Methode verwendet. Nach vielen Experimenten habe ich den System.Net.WebClient verwendet, um manuell eine Soap 1.1 und eine Soap 1.2-Anfrage zu erstellen, um das Ergebnis zu testen.

Wo das Xml ist eine Zeichenfolge-Variable des Xml mit tatsächlichen Daten. Das Problem liegt vor, wenn eines der Felder ein Sonderzeichen hat. Hier ist das Beispiel des Nachrichtentextes von xml.

<PocoClass> 
    <UnicodeString>&#xE;123</UnicodeString> 
</PocoClass> 

Wenn der Wert von Unicode wurde etwas einfach (das heißt 123), aber sobald das Sonderzeichen erschien, bekam ich 400 Bad Request.

Jetzt habe ich einen Microsoft Knowledge Base-Artikel gefunden, der den Fehler kb911276 beschreibt, der grundsätzlich besagt, dass ein Hotfix installiert wird. Das ist wirklich nicht etwas, das eine Lösung für das Problem sein könnte, also habe ich mich gefragt, ob es irgendwelche Ideen gibt, wie man dieses Problem lösen kann?

Sind die einzigen Lösungen, um eine Art benutzerdefinierte Codierung/Decodierung oder benutzerdefinierte Bindungen zu schreiben, die vom Server und Client implementiert werden? Gibt es leichtere Ideen?

Dank

Edited: Die Verwendung einer Liste ist kein Problem, da es von VS. behandelt wird Hier ist ein vollständiger (aber immer noch teilweise) Inhalt der Soap-Nachricht.

Answer 1

Ich hatte ein ähnliches Problem mit einem Webservice, den wir hatten, dass Nutzer unserer App Online-Account-Suchen durchführen. Ich habe eine VS Feedback item about this gefunden, aber es scheint, MS berücksichtigt dieses Verhalten by-design.

Am Ende haben wir eine Methode geschrieben, die alle Zeichen ersetzt, die nicht zulässig sind, wenn sie mit Fragezeichen in XML serialisiert werden.

Die erlaubte Liste war: 0x09, 0x0a, 0x0d, 0x20-0xd7ff und 0xe000-0xfffd. Alles andere haben wir uns "?" Zugewandt.

Ich denke, wenn Sie das nicht tun können, sollten die Daten im Transit base64-codiert sein, um dieses Problem zu vermeiden. Scheint ein bisschen seltsam für mich, da es die Fähigkeit zum verlustlosen Weiterleiten eines Anrufs durch einen Webdienst unterbricht.

Answer 2

Mein Anliegen ist, dass Sie angeben, dass Sie eine Liste als Parameter für eine Methode verwenden. Webdienste unterstützen Listen nicht direkt. Sie müssen ein Array als Parameter verwenden. Dann können Sie es intern mit .ToList() in eine Liste konvertieren. Dies ist möglicherweise nicht direkt Ihr Problem!

Answer 3

Dieser KB-Artikel bezog sich auf Unicode-Zeichensätze innerhalb einer Anforderungs-URL, keine tatsächlichen Daten wurden auf dem Server veröffentlicht.

Das gesagt; Ich würde überprüfen, ob Ihre Header gut formatiert sind.

Auch, wenn VS den Client-Proxy für Sie generiert hat; Klicken Sie mit der rechten Maustaste auf die Service-Referenz und dann auf "Update Service Reference"

Habe gerade noch eine Sache bemerkt; Sie haben gesagt, dass Sie eine Liste als Parameter übergeben; Aus dem Snippet von xml, das angezeigt wird, sieht das nicht wie etwas aus, das von einer Liste serialisiert werden würde (von irgendeinem der .NET XML-Serialisierer); wenn Sie mit dem Webclient-Ansatz debuggen möchten; versuchen Sie zu überprüfen, dass das Format der XML gültig ist.

Answer 4

Wo siehst du ? Im rohen XML oder den serialisierten Daten? XML ist so definiert, dass es nur für Menschen lesbare Zeichen enthält, und  ist die XML-Entität für das unlesbare ASCII-Umschalt-Zeichen. Wenn Sie sich das Roh-XML ansehen und es den XML-Entitätscode enthält, ist dies zulässig. Wenn Sie jedoch serialisierte Daten betrachten und Ihr XML-Dokument rohe Steuerzeichen enthält, ist es ungültig und wird zurückgewiesen.