Лакальны 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 падчас стварэння.

Падобныя артыкулы