Сбои веб-служб из-за (400) неверного запроса из-за специального символа

Question

Используя Visual Studio 2008, я настраиваю клиента, который использует веб-службы. Это не имеет ничего общего с размерами буфера (так как это типичный ответ, все соответствующие размеры были увеличены).

Я использовал список в качестве параметра метода. После долгих экспериментов я использовал System.Net.WebClient для создания вручную запроса Soap 1.1 и Soap 1.2 для проверки результатов теста.

using (var webCtx = new System.Net.WebClient())
{
  webCtx.Headers.Add(System.Net.HttpRequestHeader.ContentType, "text/xml");
  webCtx.Headers.Add("SOAPAction", "http://tempuri.org/HelloWorld");
  var uri = new Uri("http://localhost:12345/MyProject/WebService.asmx");
  MessageBox.Show(webCtx.UploadString(uri, xml));
}

Где xml - это строковая переменная xml с фактическими данными. Проблема в том, что одно из полей имеет специальный символ. Вот пример тела сообщения xml.

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

Если значение UnicodeString было чем-то простым (например, 123), но как только появился специальный символ, я получил 400 Bad Request.

Теперь я нашел статью базы знаний Майкрософт, описывающую ошибку kb911276 , в которой в основном говорится об установке оперативного исправления. Это действительно не то, что может быть решением проблемы, поэтому мне было интересно, есть ли идеи, как решить эту проблему?

Являются ли единственными решениями для написания какого-либо пользовательского кодирования / декодирования или пользовательских привязок, которые должны быть реализованы сервером и клиентом? Есть ли более простые идеи?

Спасибо

Отредактировано: Использование списка не является проблемой, так как он обрабатывается VS. Вот более полное (но все же частичное) содержание сообщения мыла.

<HelloWorld xmlns="http://tempuri.org/">
  <pocoList>
    <PocoClass>
      <UnicodeString>&#xE;123</UnicodeString>
    </PocoClass>
  </pocoList>
</HelloWorld>

Answer 1

У меня была похожая проблема с веб-сервисом, который у нас был, когда пользователи нашего приложения выполняли онлайн-поиск аккаунтов. Я нашел элемент VS Feedback об этом , но, похоже, MS считает, что это поведение не совсем так.

В итоге мы создали метод, который заменил все символы, которые не допускаются при сериализации в XML, на вопросительные знаки.

Допустимый список: 0x09, 0x0a, 0x0d, 0x20-0xd7ff и 0xe000-0xfffd. Ко всему прочему мы обратились к «?».

Полагаю, если вы не можете этого сделать, данные должны быть в кодировке base64, чтобы избежать этой проблемы. Мне это немного странно, так как это лишает возможности маршрутизировать вызов без потерь через веб-сервис.

Answer 2

Эта статья базы знаний ссылалась на наборы символов Юникода в URL-адресе запроса, а не на фактические данные, публикуемые на сервере.

Это, как говорится; я бы проверил, что ваши заголовки правильно сформированы.

Также, если VS сгенерировал клиентский прокси для вас; щелкните правой кнопкой мыши ссылку на службу и затем "Обновить справку службы"

Только что заметил еще одну вещь; вы сказали, что передаете список в качестве параметра; из показанного фрагмента xml это не похоже на то, что будет сериализовано из списка (любым из сериализаторов .NET xml); если вы хотите отлаживать, используя подход webclient; попробуйте убедиться, что формат xml действителен.

Answer 3

Где вы видите ? В необработанном XML или сериализованных данных? XML определен так, чтобы содержать только читаемые человеком символы, а  - это объект XML для нечитаемого символа ASCII Shift-Out. Если вы смотрите на необработанный XML и он содержит код сущности XML, это разрешено, но если вы смотрите на сериализованные данные, а ваш XML-документ содержит необработанные управляющие символы, он недопустим и будет отклонен.

Answer 4

Меня беспокоит то, что вы утверждаете, что используете список в качестве параметра метода. Веб-сервисы не поддерживают списки напрямую. Вам нужно использовать массив в качестве параметра. Затем внутренне вы можете преобразовать его в список, используя .ToList (). Это может не быть вашей проблемой напрямую!