Egy helyi WSDL még mindig kiküldheti a SoapClientet a hálózatra

Egy helyi service.wsdl továbbra is ráveheti a SoapClientet, hogy építés közben távoli dokumentumokat töltsön le. Az első fájl helyivé tétele csak azt az első letöltést szünteti meg:

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

Kezdje az első sikertelen lekérésnél, az első SOAP üzleti hívás előtt. Sorolja fel az összes WSDL-importot és schema-helyet, beleértve azokat a dokumentumokat, amelyekre ezek tovább hivatkoznak. Tartsa meg az alap URL-t vagy útvonalat, amellyel az egyes relatív hivatkozásokat feloldják. Különítse el a belső hosztokat azoktól az erőforrásoktól, amelyek valóban igénylik a külső proxyt.

Egy explicit SoapClient proxy belső sémát küldhet olyan közvetítőn keresztül, amelynek más a DNS-rálátása vagy hozzáférési szabályzata. A folyamatszintű no_proxy változó nem bizonyítja, hogy ez a betöltési útvonal olvassa. Használja a PHP-verziójához dokumentált beállításokat; egy beállítás környezeti változóról való elnevezése nem hoz létre importonkénti választót.

A definíciók teljes helyi telepítéséhez szerezze be a teljes függőségi halmaz jóváhagyott verzióit, frissítse az érintett importhelyeket a helyi csomagra, és őrizze meg a relatív útvonalak alapjait. Verziózza ezeket a dokumentumokat együtt, hogy egy új gyökér-WSDL ne használjon elavult típusokat.

Hagyja érintetlenül a namespace-azonosítókat. Úgy tűnhetnek, mint az URL-ek, de a séma szókészletét azonosítják, nem pedig azt mondják meg a betöltőnek, honnan szerezze be a fájlt. Lecserélésük megváltoztathatja a szolgáltatási szerződést.

Tesztelje újra az építést rögzített gyorsítótár-állapot mellett: a gyorsítótárazott definíciók elrejthetik az egyik gépen hiányzó függőséget. A szolgáltatás URL felülírása egy későbbi szakaszra vonatkozik, az egyedi __doRequest() pedig a SOAP-cserét kezeli; egyikről sem feltételezhető, hogy átírja vagy elfogja az összes építéskori séma-letöltést.