I am trying to create a soap client by passing a url that is hosted on my local machine, my dev environment and I keep getting this error. I use to be able to make this call and it worked just fine.
Basically all I am doing is this
$client = new SoapClient('http://virtual.website.com:81/api/?wsdl');
If I go to the url in a browser it comes up, so I know it is the right location. On the Magento forums there are some similar posts but I don't know that this is a Magento specific problem. Everything they mention as a solution I already have. They say to edit the hosts file for example 127.0.0.1 website.com
I already have this since it is setup as a virtual host.
Here is the error in my error_log
[Fri Jun 04 12:30:37 2010] [error] [client 127.0.0.1] PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://virtual.website.com:81/api/soap/?wsdl' : XML declaration allowed only at the start of the document\n in /usr/local/sites/virtual.website.com/www/CUSTOMSCRIPTS/removeProductImages.php on line 6
[Fri Jun 04 12:30:37 2010] [error] [client 127.0.0.1] PHP Stack trace:
[Fri Jun 04 12:30:37 2010] [error] [client 127.0.0.1] PHP 1. {main}() /usr/local/sites/virtual.website.com/www/CUSTOMSCRIPTS/removeProductImages.php:0
[Fri Jun 04 12:30:37 2010] [error] [client 127.0.0.1] PHP 2. SoapClient->SoapClient(*uninitialized*) /usr/local/sites/virtual.website.com/www/CUSTOMSCRIPTS/removeProductImages.php:6
UPDATE:: I have found that this isn't an issue with SOAP something is adding extra spaces to my XML file.
I had exactly the same problem. I had installed Zend Server (PHP 5.3.9) and was getting the same error. I searched a lot and applied all available solutions but all failed.
Finally, I installed wamp and then run 'Soap Client' script over there and it runs successfully.
Then I reached on this point that Zend Server (PHP 5.3.9) has some default bug in 'Soap Client' Script. I uninstalled Zend Server (PHP 5.3.9) and installed Zend Server (PHP 5.4.11) and runs 'Soap Client' script over there. This time it runs successfully.
Conclusion:
Please use latest PHP version (Zend Server) or (Wamp Server) as, there is default 'Soap Client' bug in some PHP versions, one I mentioned above.
After changing URL settings of Magento or your local environment you should always clear Magento /var/cache/ directory. Usually all weird errors disappear with it.
The answer seemed to be for us that we had not enabled the xmlrpc PHP extension. Once we did that the error went away.
Also the problem could be related to rights on soap.wsdl_cache_dir directory
I solved this on my WAMP setup by enabling the php_openssl extension, since the URL I was loading from used https://.
Related
I'm deploying a web server, and the server is running bitnami. When I try to upload a file to the server, it returns 400 errors, bad request. I read the error log of bitnami (because the code works on another server) and It has the following message:
[Wed Feb 10 15:11:33.103754 2021] [proxy_fcgi:error] [pid 10113:tid 140226278139648] (11)Resource temporarily unavailable: [client xxxxxxxx:64905] AH01075: Error dispatching request to : (reading input brigade), referer: http://xxxxxxx/test.php
I have verified the limit to upload, timely execution, php.ini, etc. And I search for information about the error but I can't find information about it. What do the reasons maybe? Thank you for your comments
My WP installation generates a Internal Error 500 every time I activate the BuddyPress plugin.
This is the actual error:
[Sat Mar 28 19:12:28.102868 2015] [fastcgi:error] [pid 10447] (104)Connection reset by peer: [client 192.168.1.1:55431] FastCGI: comm with server "/var/www/clients/client1/web4/cgi-bin/php5-fcgi-*-80-site.eu" aborted: read failed, referer: http://site.eu/wp-admin/update.php?action=install-plugin&plugin=buddypress&_wpnonce=54e15a2310
[Sat Mar 28 19:12:28.103055 2015] [fastcgi:error] [pid 10447] [client 192.168.1.1:55431] FastCGI: incomplete headers (0 bytes) received from server "/var/www/clients/client1/web4/cgi-bin/php5-fcgi-*-80-site.eu", referer: http://site.eu/wp-admin/update.php?action=install-plugin&plugin=buddypress&_wpnonce=54e15a2310`
How should I solve that?
P.S. The strange thing is that before, when the server was running Ubuntu 12, I had no troubles activating and using BuddyPress. Then something possessed me and I decided to upgrade the OS to 14.04 and as a result the site became inaccessible. Finally, I figured that it was BuddyPress that was causing the issue, removed it from the plugins folder and the site went back to working. Now every time I try to re-add BP, I get the error above.
According to this post, installing this plugins cause the fcgi process for PHP to hit its memory limit or execution time limit, preventing it to properly finish.
First of all, thank you for your time in reading this :)
I am managing a server which runs apache2 and mod_fcgi which host a few sites via Virtual Hosts. Some sites are straight PHP, the others are all WordPress. The WordPress sites are all functioning great, however, any other site throws up a 500 Internal Server Error when you try to access them.
If you navigate to a non-php file on the web directory (like an image) it will display, but any .php file throws up this error.
The Apache2 error log shows nothing.
When I tail the error log of the site, I get this:
[Wed May 22 15:12:15 2013] [warn] [client x.x.x.x] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[Wed May 22 15:12:15 2013] [error] [client x.x.x.x] Premature end of script headers: php-fcgi-wrapper
[Wed May 22 15:12:15 2013] [debug] mod_deflate.c(615): [client x.x.x.x] Zlib: Compressed 612 to 377 : URL /fcgi-bin/php-fcgi-wrapper/index.php
The root of the website is located in /var/www/site1/
I have quadrouple-checked my permissions and ownerships.
I have increased more memory for PHP.
I tried looking at the php.log file, but nothing is being written.
Can anyone point anything else out that could be causing this?
Thank you!
I don't have the time at the moment to back up my cgi-conflict suggestion, but it occurred to me that you may be using php short tags, when the server doesn't allow it. Wordpress I believe uses full open tags which would explain why it works.
Instead of using:
<? //some php code
?>
Try:
<?php //some php code
?>
Are you using short tags? This could be your issue.
I'm trying to request to a web service which is using WS Security and based on signing method(private public keys), as I've successfully installed wsf library but still when I hit the url it generate these error logs.
REQUEST URL
http://localhost/wsf/samples/security/signing/client.php
RESPONSE
Message = ws client create failed
Error Log GENERATED in wsf_c/logs
[Fri Feb 3 15:00:23 2012] [error] class_loader.c(152) Loading shared library /opt/lampp/htdocs/wsf/wsf_c/lib/libaxis2_http_receiver.so Failed. DLERROR IS /opt/lampp/htdocs/wsf/wsf_c/lib/libaxis2_http_receiver.so: cannot open shared object file: No such file or directory
[Fri Feb 3 15:00:23 2012] [error] conf_builder.c(1156) Transport receiver loading failed for libaxis2_http_receiver.so, unable to continue
[Fri Feb 3 15:00:23 2012] [error] conf_builder.c(263) Processing transport receivers failed, unable to continue
[Fri Feb 3 15:00:23 2012] [error] dep_engine.c(928) Populating Axis2 Configuration failed
[Fri Feb 3 15:00:23 2012] [error] conf_init.c(225) Loading deployment engine failed for client repository /opt/lampp/htdocs/wsf/wsf_c
[Fri Feb 3 15:03:01 2012] [error] class_loader.c(152) Loading shared library /opt/lampp/htdocs/wsf/wsf_c/lib/libaxis2_http_receiver.so Failed. DLERROR IS /opt/lampp/htdocs/wsf/wsf_c/lib/libaxis2_http_receiver.so: cannot open shared object file: No such file or directory
Someone kindly tell me how to fix it Thanks
I think you have the libraries in the wrong place, (but they could be entirely correct for your system)
Do any of the other samples work for you?
I'm using Ubuntu 12.04 and have them in
'/usr/lib/php5/20090626+lfs/wfc/lib'
you might need to set your wfc.home Directive in your php.ini
I have the following in /etc/php5/conf.d/wsf.ini
(my Apache/php loads all the ini files under conf.d on startup)
; configuration for php WSF module
extension=wsf.so
include_path=".:/usr/share/php:/home/haydn/Downloads/wso2/scripts"
[wsf]
wsf.home="/usr/lib/php5/20090626+lfs/wsf_c"
Hope This Helps
I have configured php to log errors and on my development machine, they show up in the apache error logs as:
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Parse error: syntax error, unexpected ')' in /Users/troelskn/Projects/test/bootstrap.inc.php on line 27
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Stack trace:
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP 1. {main}() /Users/troelskn/Projects/test/public/index.php:0
However, on the production machines (Ubuntu) there is no stacktrace following the error and there is a referrer attached to the message. Eg. it would look like:
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Parse error: syntax error, unexpected ')' in /Users/troelskn/Projects/test/bootstrap.inc.php on line 27, referer: http://localhost/
How can I control this formatting? I would very much like to have the stacktrace available in the logs.
Well, as has already been pointed out, you're not getting the same formatting on the live machine because the live machine hasn't got xdebug installed. There is debug_backtrace but that wouldn't catch a fatal error.
You could install xdebug on the live server, but you'd have to be very careful to configure it to expose no functionality except for the stack trace logging. Incautious use of xdebug on a live box could pose a security risk as people could initiate a remote debug session, or its enhanced error messages could inadvertently echo out internal details of your code.
To be honest? I'd think your best option is to try and recreate the circumstances under which the error the live server logged occurred on your test server.
EDIT TO ADD: Forgot to mention that in addition to being a security risk, xDebug will also have a negative impact on your website's performance. It hooks into Zend Engine in several crucial ways to log programme state and alter its behaviour (such as overriding # error suppression), and this will have an inevitable impact on performance. You're basically far better off trying to replicate the issue on a testing environment than you are adding debugging tools to a live one.
You can trace by using debug_backtrace or debug_print_backtrace though I never used them. Best tracing come from from xdebug or Zend debugger. I agree with Gordon that you should not install a debugger on a production machine.