En lokal WSDL kan ändå skicka SoapClient ut på nätet

En lokal service.wsdl kan fortfarande få SoapClient att hämta fjärrdokument under konstruktionen. Att göra den första filen lokal tar bara bort den första nedladdningen:

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

Börja vid den första misslyckade hämtningen, före det första affärsanropet via SOAP. Lista varje WSDL-import och varje schema location, inklusive de dokument som de i sin tur refererar till. Behåll bas-URL:en eller sökvägen som används för att lösa varje relativ referens. Skilj interna värdar från resurser som verkligen behöver den externa proxyn.

En explicit SoapClient-proxy kan skicka ett internt schema via en mellanhand med annan DNS-vy eller åtkomstpolicy. En no_proxy-variabel på processnivå bevisar inte att denna laddningsväg läser den. Använd de alternativ som är dokumenterade för din PHP-version; att namnge ett alternativ efter en miljövariabel skapar ingen väljare per import.

För att distribuera definitionerna helt lokalt, skaffa de godkända versionerna av hela beroendemängden, uppdatera de aktuella importplatserna till det lokala paketet och behåll deras relativa sökvägsbaser. Versionshantera dessa dokument tillsammans så att en ny rot-WSDL inte använder inaktuella typer.

Rör inte namnrymdsidentifierare. De kan se ut som URL:er, men de identifierar schemaordförrådet i stället för att tala om för inläsaren var en fil ska hämtas. Att ersätta dem kan ändra tjänsteavtalet.

Testa konstruktionen igen med cacheläget registrerat: cachade definitioner kan dölja ett saknat beroende på en maskin. En överstyrning av tjänstens URL gäller i ett senare skede, och en anpassad __doRequest() hanterar SOAP-utbytet; ingen av dem bör antas skriva om eller fånga upp alla schema-nedladdningar vid konstruktionstidpunkten.