Как отделить неверный Content-Type, секцию выполнения политики, schema-id, пространство имён XML и режим detect или prevent, не меняя production-политику вслепую.
Разделите симптом на пять проверок
Сообщение «валидация не работает» не показывает, дошёл ли запрос до нужной политики и что именно сравнивалось. Сначала запишите фактический Content-Type, раздел pipeline, значение schema-id, корневой элемент с namespace и выбранное действие при ошибке. Microsoft указывает, что validate-content умеет проверять XML по зарегистрированной схеме и применяется в определённых секциях политики. Поэтому одинаковый XSD при разных заголовках или в другой секции — уже разные эксперименты. Не меняйте несколько полей одновременно: иначе успешный результат нельзя будет связать с конкретной причиной.
Соберите контрольную пару XML
Создайте два коротких обезличенных документа с одним и тем же корневым элементом. Первый должен соответствовать обязательным элементам и типам вашей XSD, второй — отличаться ровно одним нарушением, например пропущенным обязательным полем или неверным типом. Отправляйте их одним методом и с одинаковым Content-Type в непродуктивный API или согласованное тестовое окно. Если оба проходят, переходите к размещению политики и schema-id. Если оба отклоняются, сначала сверяйте namespace и структуру валидного образца. Реальный пользовательский payload для этой проверки не нужен.
Не смешивайте detect и prevent
Режим detect фиксирует ошибку и позволяет обработке продолжиться, а prevent прекращает запрос согласно настройке политики. Поэтому отсутствие немедленного отказа ещё не означает отсутствие результата валидации. До теста запишите ожидаемое действие и имя переменной ошибок, если она используется. Затем сравните код ответа, секцию on-error и доступную trace-запись. Не переводите production в prevent только ради видимого отказа: сначала докажите поведение на контрольной паре. Если трассировка содержит данные запроса, удалите тела, токены и адреса перед передачей.
Когда остановиться и что эскалировать
Остановите правки, если результат меняется вместе с несколькими параметрами, схема подменяется вручную или нет отдельной тестовой поверхности. Для поддержки подготовьте идентификатор API и операции, секцию политики, нейтральное имя schema-id, Content-Type, namespace, режим действия, два ожидаемых результата и UTC-время прогонов. Приложите только очищенный фрагмент политики и trace без ключей подписки, Authorization, персональных полей и полного XSD, если схема конфиденциальна. Полезный вывод формулируется узко: какая одна комбинация принимает валидный документ и отклоняет документ с одним контролируемым нарушением.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; факты вручную сверены с официальной документацией Azure API Management, а публичная ветка использована только как обезличенный сигнал.
Источники и проверка
- Microsoft Learn — validate-content policy reference проверено 2026-07-31
- Microsoft Learn — Policies in Azure API Management проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.