I’ve run across an interesting PHP/SOAP error that has me stymied. After searching I have not found a plausible explanation, and I’d appreciate your help. Here’s the background:
I have a site built in PHP/CodeIgniter which uses SOAP to communicate over SSL with a back-end system provided by a third party (let’s call them ‘Company X’ to protect the innocent) not in my control. In the spirit of good MVC, I put the code specific to interacting with that data source in a separate model (system/application/models/company_x.php). I have been developing locally using MAMP on my Mac, and just about everything was relatively smooth through testing and development; including calling Company X’s web service over SSL. I should probably mention that their web service had strange WSDL that PHP 5’s SOAP didn’t like. Things like required parameters that were not there. It’s been a little odd to call SOAP methods very explicitly, but I got it going and it worked through testing. I even deployed it to a test site at Mosso, and I could have sworn that it worked for a time up there too.
Imagine my surprise when every call to the SOAP web service starting producing errors like the following:
A PHP Error was encountered Severity: Warning Message: SoapClient::__doRequest() [soapclient.--dorequest]: WARNING: URL fopen access Filename: models/company_x.php Line Number: 86
The error logs didn’t give any more information other than the full path to the model file on the server. It works locally, and I thought it worked on Mosso before. Maybe Mosso changed their settings, and disabled SOAP or something. A little phpinfo() later, and they have more than enough. I thought that maybe my Mac is more tolerant of the SSL certificate. After all, it’s a GoDaddy *.domain.com cert, maybe fopen is having trouble getting through. I whipped up a test file to connect over SSL, and put it on Mosso and it worked.
I’m wondering why is fopen access suddenly a problem for SOAP? What is it about Mosso that is making this difficult suddenly? Do I need to override some php.ini setting? Could it be, like is so often with unhelpful errors like this, something completely different?
Update: here is the configure command from phpinfo():
'./configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-ming' '--with-mime-magic' '--with-sqlite=shared' '--with-libxml-dir=/usr' '--with-xml' '--with-system-tzdata' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--without-odbc' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--disable-json'
Note: My comment below that phpinfo() reports that furl is allowed; weird!
OK, a little update on this problem: the error mysteriously disappeared without any change from me. I will have to assume that there was some odd configuration error on Mosso that was silently fixed. It is also remotely possible that there was a problem with Company X’s setup. That is the worst kind of fix IMO! Thanks anyway to everyone who looked in on this.