Vietinis WSDL vis tiek gali išsiųsti SoapClient į tinklą

Sekite pereinamuosius WSDL ir XML Schema importus, kai vietinė paslaugos apibrėžtis vis dar maišo vidinius ir išorinius proxy maršrutus.

Vietinis service.wsdl vis tiek gali priversti SoapClient kūrimo metu gauti nuotolinius dokumentus. Pirmo failo pavertimas vietiniu pašalina tik tą pirmą atsisiuntimą:

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

Pradėkite nuo pirmo nepavykusio gavimo, prieš pirmą SOAP verslo iškvietimą. Išvardykite kiekvieną WSDL importą ir kiekvieną schema location, įskaitant dokumentus, į kuriuos jie savo ruožtu nurodo. Išsaugokite bazinį URL arba kelią, naudojamą kiekvienai santykinei nuorodai išspręsti. Atskirkite vidinius hostus nuo išteklių, kuriems tikrai reikia išorinio proxy.

Aiškus SoapClient proxy gali siųsti vidinę schema per tarpininką, turintį kitokį DNS vaizdą ar prieigos politiką. Procesų lygio no_proxy kintamasis neįrodo, kad šis įkėlimo kelias jį skaito. Naudokite jūsų PHP versijai dokumentuotas parinktis; parinkties pavadinimas pagal aplinkos kintamąjį nesukuria kiekvieno importo selektoriaus.

Norėdami apibrėžtis visiškai įdiegti vietoje, gaukite patvirtintas viso priklausomybių rinkinio versijas, atnaujinkite susijusias importo vietas į vietinį paketą ir išsaugokite jų santykinių kelių bazes. Versijuokite tuos dokumentus kartu, kad naujas šakninis WSDL nenaudotų pasenusių tipų.

Nelieskite namespace identifikatorių. Jie gali atrodyti kaip URL, bet identifikuoja schema žodyną, o ne nurodo įkėlikliui, iš kur gauti failą. Jų pakeitimas gali pakeisti paslaugos sutartį.

Dar kartą patikrinkite kūrimą užfiksavę podėlio būseną: podėlyje laikomos apibrėžtys gali paslėpti vienoje mašinoje trūkstamą priklausomybę. Paslaugos URL perrašymas taikomas vėlesniam etapui, o tinkinta __doRequest() tvarko SOAP mainus; nereikėtų manyti, kad kuris nors iš jų perrašo ar perima visus schema atsisiuntimus kūrimo metu.

Susiję straipsniai