Un WSDL locale può comunque mandare SoapClient sulla rete

Un service.wsdl locale può ancora far sì che SoapClient recuperi documenti remoti durante la costruzione. Rendere locale il primo file elimina solo quel primo download:

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

Partite dal primo recupero non riuscito, prima della prima chiamata business SOAP. Elencate ogni import WSDL e ogni schema location, compresi i documenti a cui questi rimandano a loro volta. Conservate l'URL o il percorso di base usato per risolvere ogni riferimento relativo. Separate gli host interni dalle risorse che hanno davvero bisogno del proxy esterno.

Un proxy SoapClient esplicito può inviare uno schema interno attraverso un intermediario con una vista DNS o una politica di accesso diverse. Una variabile no_proxy a livello di processo non dimostra che questo percorso di caricamento la legga. Usate le opzioni documentate per la vostra versione di PHP; dare a un'opzione il nome di una variabile d'ambiente non crea un selettore per import.

Per distribuire le definizioni interamente in locale, procuratevi le versioni approvate dell'intero insieme di dipendenze, aggiornate le posizioni di import interessate al pacchetto locale e conservate le loro basi di percorso relativo. Versionate quei documenti insieme, così un nuovo WSDL radice non usi tipi obsoleti.

Non toccate gli identificatori di namespace. Possono sembrare URL, ma identificano il vocabolario dello schema invece di dire al caricatore dove recuperare un file. Sostituirli può cambiare il contratto del servizio.

Verificate di nuovo la costruzione con lo stato della cache registrato: le definizioni in cache possono nascondere una dipendenza mancante su una macchina. L'override dell'URL del servizio si applica a una fase successiva, e un __doRequest() personalizzato gestisce lo scambio SOAP; nessuno dei due va dato per scontato come riscrittura o intercettazione di tutti i download di schema in fase di costruzione.