Een lokale WSDL kan SoapClient alsnog het netwerk op sturen

Een lokale service.wsdl kan SoapClient er nog steeds toe brengen tijdens de constructie externe documenten op te halen. Het eerste bestand lokaal maken verwijdert alleen die eerste download:

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

Begin bij de eerste mislukte ophaling, vóór de eerste zakelijke SOAP-aanroep. Lijst elke WSDL-import en elke schema-locatie op, inclusief de documenten waarnaar die op hun beurt verwijzen. Bewaar de basis-URL of het pad dat wordt gebruikt om elke relatieve verwijzing op te lossen. Scheid interne hosts van resources die echt de externe proxy nodig hebben.

Een expliciete SoapClient-proxy kan een intern schema via een tussenpartij met een andere DNS-weergave of toegangsbeleid sturen. Een no_proxy-variabele op procesniveau bewijst niet dat dit laadpad die leest. Gebruik de opties die voor uw PHP-versie zijn gedocumenteerd; een optie naar een omgevingsvariabele vernoemen maakt geen selector per import.

Om definities volledig lokaal uit te rollen, haal de goedgekeurde versies van de hele afhankelijkheidsset, werk de betreffende importlocaties bij naar de lokale bundel en behoud hun relatieve padbases. Versionneer die documenten samen zodat een nieuwe root-WSDL geen verouderde typen gebruikt.

Laat namespace-identificaties met rust. Ze lijken misschien op URL's, maar ze identificeren de schema-woordenschat in plaats van de lader te vertellen waar een bestand te halen. Ze vervangen kan het servicecontract wijzigen.

Test de constructie opnieuw met de cache-status vastgelegd: gecachte definities kunnen een ontbrekende afhankelijkheid op één machine verbergen. Een overschrijving van de service-URL geldt in een latere fase, en een aangepaste __doRequest() handelt de SOAP-uitwisseling af; van geen van beide moet worden aangenomen dat ze alle schema-downloads tijdens de constructie herschrijven of onderscheppen.