En lokal WSDL kan stadig sende SoapClient ud på netværket
Følg transitive WSDL- og XML Schema-imports, når en lokal tjenestedefinition stadig blander interne og eksterne proxy-ruter.
En lokal service.wsdl kan stadig få SoapClient til at hente fjernedokumenter under konstruktionen. At gøre den første fil lokal fjerner kun den første download:
local service.wsdl
→ internal Common.xsd
→ external Types.xsd
→ another schema location
Start ved den første mislykkede hentning, før det første SOAP-forretningskald. List hvert WSDL-import og hver schema-location, inklusive de dokumenter, de igen refererer til. Bevar den basis-URL eller -sti, der bruges til at opløse hver relativ reference. Skeln interne hosts fra ressourcer, der reelt har brug for den eksterne proxy.
En eksplicit SoapClient-proxy kan sende et internt schema gennem en mellemmand med et andet DNS-syn eller en anden adgangspolitik. En no_proxy-variabel på procesniveau beviser ikke, at denne indlæsningsvej læser den. Brug de muligheder, der er dokumenteret for din PHP-version; at opkalde en mulighed efter en miljøvariabel skaber ikke en selektor pr. import.
Hvis definitionerne skal udrulles helt lokalt, skaf de godkendte versioner af hele afhængighedssættet, opdater de relevante importplaceringer til det lokale bundle, og bevar deres relative stibaser. Versionsstyr disse dokumenter sammen, så en ny rod-WSDL ikke bruger forældede typer.
Lad namespace-identifikatorer være. De kan ligne URL'er, men de identificerer schema-ordforrådet i stedet for at fortælle indlæseren, hvor en fil skal hentes. Hvis de erstattes, kan tjenestekontrakten ændre sig.
Test konstruktionen igen med cache-tilstanden registreret: cachede definitioner kan skjule en manglende afhængighed på én maskine. En tilsidesættelse af tjeneste-URL'en gælder i en senere fase, og en brugerdefineret __doRequest() håndterer SOAP-udvekslingen; ingen af dem bør antages at omskrive eller opsnappe alle schema-downloads på konstruktionstidspunktet.