Un WSDL local puede seguir enviando SoapClient a la red

Un service.wsdl local todavía puede hacer que SoapClient obtenga documentos remotos durante la construcción. Hacer local el primer archivo solo elimina esa primera descarga:

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

Empiece por la primera recuperación fallida, antes de la primera llamada de negocio SOAP. Enumere cada importación de WSDL y cada ubicación de esquema, incluidos los documentos a los que estos remiten a su vez. Conserve la URL base o la ruta usada para resolver cada referencia relativa. Separe los hosts internos de los recursos que realmente necesitan el proxy externo.

Un proxy de SoapClient explícito puede enviar un esquema interno a través de un intermediario con una vista DNS o una política de acceso distintas. Una variable no_proxy a nivel de proceso no demuestra que esta ruta de carga la lea. Use las opciones documentadas para su versión de PHP; nombrar una opción como una variable de entorno no crea un selector por importación.

Para desplegar las definiciones por completo en local, obtenga las versiones aprobadas de todo el conjunto de dependencias, actualice las ubicaciones de importación aplicables al paquete local y conserve sus bases de rutas relativas. Versione esos documentos en conjunto para que un nuevo WSDL raíz no use tipos obsoletos.

No toque los identificadores de espacio de nombres. Pueden parecer URL, pero identifican el vocabulario del esquema en lugar de indicar al cargador de dónde obtener un archivo. Reemplazarlos puede cambiar el contrato del servicio.

Vuelva a probar la construcción con el estado de la caché registrado: las definiciones en caché pueden ocultar una dependencia faltante en una máquina. La anulación de la URL del servicio se aplica en una etapa posterior, y un __doRequest() personalizado gestiona el intercambio SOAP; no debe suponerse que ninguno de los dos reescriba o intercepte todas las descargas de esquema en tiempo de construcción.