Локальний WSDL усе ще може відправити SoapClient у мережу

Відстежуйте транзитивні імпорти WSDL і XML Schema, коли локальний опис сервісу все ще змішує внутрішні та зовнішні proxy-маршрути.

Локальний service.wsdl усе ще може змусити SoapClient завантажувати віддалені документи під час створення. Локалізація першого файлу прибирає лише це перше завантаження:

local service.wsdl
  → internal Common.xsd
  → external Types.xsd
       → another schema location

Почніть із першого невдалого отримання, до першого бізнес-виклику SOAP. Перелічіть кожен імпорт WSDL і кожне розташування schema, включно з документами, на які вони своєю чергою посилаються. Зберігайте базовий URL або шлях, що використовується для розв'язання кожного відносного посилання. Відокремлюйте внутрішні хости від ресурсів, яким справді потрібен зовнішній proxy.

Явний proxy SoapClient може надіслати внутрішню schema через посередника з іншим поданням DNS або іншою політикою доступу. Змінна no_proxy рівня процесу не доводить, що цей шлях завантаження її читає. Використовуйте опції, задокументовані для вашої версії PHP; називання опції на честь змінної середовища не створює селектор для кожного імпорту.

Щоб повністю розмістити описи локально, отримайте затверджені версії всього набору залежностей, оновіть відповідні місця імпорту на локальний пакет і збережіть їхні бази відносних шляхів. Версіонуйте ці документи разом, щоб новий кореневий WSDL не використовував застарілі типи.

Не чіпайте ідентифікатори просторів імен. Вони можуть виглядати як URL, але визначають словник schema, а не підказують завантажувачу, звідки брати файл. Їх заміна може змінити контракт сервісу.

Повторно перевірте створення із зафіксованим станом кешу: кешовані описи можуть приховувати відсутню залежність на одній машині. Перевизначення URL сервісу діє на пізнішому етапі, а користувацький __doRequest() обробляє обмін SOAP; не можна вважати, що будь-який із них переписує або перехоплює всі завантаження schema під час створення.

Схожі статті