Yerel bir WSDL yine de SoapClient'ı ağa çıkarabilir

Yerel bir hizmet tanımı hâlâ iç ve dış proxy yollarını karıştırdığında geçişli WSDL ve XML Schema içe aktarımlarını izleyin.

Yerel bir service.wsdl, SoapClient'ın oluşturma sırasında uzak belgeleri getirmesine hâlâ yol açabilir. İlk dosyayı yerel yapmak yalnızca o ilk indirmeyi ortadan kaldırır:

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

İlk SOAP iş çağrısından önce, ilk başarısız getirmeden başlayın. Her WSDL içe aktarımını ve her schema location'ı, bunların da başvurduğu belgelerle birlikte listeleyin. Her göreli başvuruyu çözmek için kullanılan temel URL'yi veya yolu koruyun. İç ana makineleri gerçekten dış proxy'ye ihtiyaç duyan kaynaklardan ayırın.

Açık bir SoapClient proxy, farklı bir DNS görünümüne veya erişim ilkesine sahip bir aracı üzerinden iç schema gönderebilir. Süreç düzeyindeki no_proxy değişkeni, bu yükleme yolunun onu okuduğunu kanıtlamaz. PHP sürümünüz için belgelenmiş seçenekleri kullanın; bir seçeneği ortam değişkenine göre adlandırmak içe aktarım başına seçici oluşturmaz.

Tanımları tamamen yerel olarak dağıtmak için tüm bağımlılık kümesinin onaylanmış sürümlerini edinin, ilgili içe aktarım konumlarını yerel pakete güncelleyin ve göreli yol tabanlarını koruyun. Yeni bir kök WSDL'nin eski türleri kullanmaması için bu belgeleri birlikte sürümleyin.

Ad alanı tanımlayıcılarına dokunmayın. URL gibi görünebilirler, ancak yükleyiciye dosyanın nereden alınacağını söylemek yerine schema sözlüğünü tanımlarlar. Bunları değiştirmek hizmet sözleşmesini değiştirebilir.

Önbellek durumunu kaydederek oluşturmayı yeniden test edin: önbelleğe alınmış tanımlar bir makinede eksik bir bağımlılığı gizleyebilir. Hizmet URL'sinin geçersiz kılınması daha sonraki bir aşamada geçerlidir ve özel bir __doRequest() SOAP alışverişini yürütür; ikisinin de oluşturma sırasındaki tüm schema indirmelerini yeniden yazdığı veya yakaladığı varsayılmamalıdır.

İlgili makaleler