php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #34854 Extend SOAPClient WSDL param to take literal string or local path
Submitted: 2005-10-13 12:58 UTC Modified: 2005-10-13 13:28 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: marcus at synchromedia dot co dot uk Assigned:
Status: Wont fix Package: Feature/Change Request
PHP Version: 5CVS-2005-10-13 (snap) OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: marcus at synchromedia dot co dot uk
New email:
PHP Version: OS:

 

 [2005-10-13 12:58 UTC] marcus at synchromedia dot co dot uk 
Description:
------------
This is a minor thing that's been troubling me, making it 
difficult to deploy a salesforce.com SOAP client across 
multiple projects. Salesforce is a particular interest 
because its WSDL files are not available directly online - 
you have to download and save local copies manually.

When constructing a SOAPClient object, the WSDL parameter 
provided is treated like a URL (because it will usually BE a 
URL). For 'local' URLs, it searches the current directory, 
including any relative path that it uses. However, because 
it is fundamentally a URL and not a file request like an 
include, it does not search the include path. The net result 
of this is that I'm having to copy my WSDL files into every 
place that my class library is called from because the URL 
resolution will only ever look in the calling directory and 
not in the include path that allowed it to find my classes.

An alternative would be to allow providing the WSDL as a 
literal string, probably read using file_get_contents() 
which does support using the include path.

A worse solution is to provide the WSDL contents as the 
response to a separate HTTP call (i.e. act like the WSDL is 
online after all). This would work, but it's way less 
efficient. It's also hard to configure across multiple 
installations.

I can't use an absolute path as it's deployed in multiple 
configurations on multiple servers, and config is bad enough 
already.

So, please can you either extend the WSDL parameter to 
accept a literal string or a local path that's not handled 
as a URL.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-13 13:03 UTC] tony2001@php.net 
>I'm having to copy my WSDL files into every 
>place that my class library is called from because the URL 
>resolution will only ever look in the calling directory and 
>not in the include path that allowed it to find my classes.

Why not to use absolute path then?
 [2005-10-13 13:12 UTC] marcus at synchromedia dot co dot uk 
Because for any given deployment, the absolute path may be 
different, simply because some servers put stuff in different 
places, or because it's in a different virtual host etc. Both 
of those situations are normally handled using the include 
path, but in this case we're denied that possibility.
 [2005-10-13 13:16 UTC] tony2001@php.net 
>Because for any given deployment, the absolute path may be 
different.
Yeah, that's the reason to have a configuration variable.

I honestly don't see a reason for SOAPClient to use include_path.
So it's a "Won't fix".
 [2005-10-13 13:28 UTC] marcus at synchromedia dot co dot uk 
> Yeah, that's the reason to have a configuration variable.

Well, that's what I'm trying to avoid. The issue is really 
that SOAPClient's local path support acts differently from 
nearly every other use of local paths. The WSDL is part of 
my class library, but I can't treat it as such because I 
can't rely on it being found.

If not include_path, then accepting a literal string 
containing the WSDL data would be a good substitute, and 
would also work well in cases where the WSDL is held in a 
local DB.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun May 19 09:01:36 2024 UTC