I'm using Eclipse and XDebug to develop a PHP application that relies on web services.
I have test pages that consume my services in 2 ways: AJAX (using jQuery) and cURL.
I add breakpoints to my service page and launch the debugger. When I call the the service from AJAX, execution stops nicely at the breakpoint, and I get my variables, step-by-step control etc.
But when I call the service using cURL (i.e. from within a PHP page), the breakpoints fail to function. Even if I turn on the "Break at first line" debugger option, I cannot get the execution to stop when using cURL.
Is it a debugger behavior? Do I need to add a hearder to my cURL calls? Alter the URL? Or is it an XDebug limitation?
Thanks for your time and effort,
Guy
I can't comment yet, so I post this as an answer.
Can you debug more than one AJAX request in one session?
Was your debug session still running in Eclipse when you tried to debug using cURL?
Description on how it works for me:
Start debug session with a simple debug.php file that contains only a <?php and nothing else. It stops on the first line, you "continue" it and it finishes execution.
Now request the script using cURL (or another browser) adding ?XDEBUG_SESSION_START=ECLIPSE_DBGP to its path (I even think this addition is optional)
Your script should show up in the debug view stopped at the first line
Hope ths helps.
Here is tip on how to trigger Xdebugger client from Curl without browser:
1- From command line:
curl -H "Cookie: XDEBUG_SESSION=1" http://YOUR-SITE.com/your-script.php
2- From PHP
<?php
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL, 'http://YOUR-SITE.com/your-script.php');
curl_setopt ($ch, CURLOPT_COOKIE, 'XDEBUG_SESSION=1');
curl_exec ($ch);
?>
So it doesn't matter if you attach "XDEBUG_SESSION=1" to CURL URL, but what is necessary is to send a proper cookie together with request.
I know this is a pretty old thread, but I thought I'd post my experience for others that may come across it, like I did, with the same problem. What I discovered is that, if you are debugging remotely (which I always do), there are a couple settings you have to change in php.ini to make this work. Here are the ones that worked for me:
xdebug.remote_connect_back = false
xdebug.remote_host = {client host name or IP}
The first setting is normally "true," and tells xdebug to look for the client at the same IP address where the HTTP request originated. In this case however, the request is coming from the server, so that won't work. Instead you must use the second setting to tell xdebug where to find the client. Hope this helps save somebody a little time!
To trigger the debugger the simplest solution is to use the cookie approach -b XDEBUG_SESSION=ECLIPSE_DBGP worked for me on eclipse, see below:
curl -H 'Content-type: application/json' \
-b XDEBUG_SESSION="ECLIPSE_DBGP" \
-X POST \
-d '{"uid":200, "message":"asdsad","message_type":1}'
http://daxuebao.local:8083/api/message/send
When you are debugging the Ajax request, that one is sent by the browser, in the same navigation context as the other (non-Ajax) requests -- which is why it works fine.
The request sent by curl is in another, different, context -- and I'm not sure you can hook the debugger into that... But, maybe...
First of all, here's an information that might prove helpful, quoting the Xdebug's documentation :
Xdebug contains functionality to keep
track of a debug session when started
through a browser: cookies. This works
like this:
When the URL variable XDEBUG_SESSION_START=name is
appended to an URL Xdebug emits a
cookie with the name
"XDEBUG_SESSION" and as value the
value of the XDEBUG_SESSION_START
URL parameter.
When there is a GET (or POST) variable XDEBUG_SESSION_START or the
XDEBUG_SESSION cookie is set, Xdebug
will try to connect to a debugclient.
To stop a debug session (and to destroy the cookie) simply add the URL
parameter XDEBUG_SESSION_STOP.
Xdebug will then no longer try to make
a connection to the debugclient.
Maybe it might work if you set that cookie "by hand", sending it allong the curl request...
I suppose you'd first have to get its value, as set by Xdebug at the beginning of the debugging session -- re-using the cookie you have in your browser should be possible, though.
Note : I've never tried this -- if you try, and it works, could you please confirm it worked ?
I ran into this same exact issue. I solved it by turning the auto-start feature off in php.ini:
xdebug.remote_autostart = 0
and then adding the API key to the webservice URL that my webservice client calls:
?XDEBUG_SESSION_START=<your API key here>
and I'm not sure if this matters, but I entered the API key into my debugger (MacGDBp). Now the debugger fires up only when the webervice server-side script is called, not when the client is started.
Hope this helps.
Related
This only happens on my webserver, not on the local system.
I have a curl request like this
ini_set('display_errors', 1);
error_reporting(E_ALL);
$url = 'http://***.***.***.***:8080/api_v1/oauth/token';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
$response = curl_exec($ch);
This makes the page loading for a while and just returns a white screen. It is really impossible to show errors, output or just anything else.
Whenever I change the url to another url (existing or not existing) i get proper errors or output if the url makes sense, as long as the url does not contain any dots or colons...
Is there any restriction for the usage or a curlopt I am missing?
I have no control over the target url, I need to consume the api in the ip:port structure.
UPDATE
The problem is not related to the target URL or data coming in: the same problem occurs when I enter a url that makes no sense at all as long as it doesn't contain . or :
I guess it is a setting on the webserver since all my tests work fine on localhost (MAMP)
Unfortunately I have no access to any logs or files except the ones I upload myself (one.com webhosting)
UPDATE 2
Turns out my hoster is blocking all outgoing traffic to implicit IP's and ports other than 80 and 443.
Cancelled my subscription and taking a decent provider now.
Thanks for the help
As #Quasimodo suggests, then I'd take a look in the log-file, if I were you. If you're on a Ubuntu-server using Apache, then look at /var/log/apache2/error.log. A neat trick is to open a terminal and write:
tail -f /var/log/apache2/error.log
This will open a running stream to the terminal. Then you can make your curl-request crash (in your browser) and then go back to the terminal and see what new and juicy errors you have received.
It's most likely some configuration-file on your server. So it would be helpful, if you write a couple of specs from that server, such as:
- Which web server you're using (Apache, Nginx, other)
- PHP version
... You can find all of these information easily using phpinfo.
My best guess is that you need to enable PHP_Curl for your server configuration, - but it is a buck-wild cowboy shot from the hip.
Addition 1
I can see that you've just editted the question (that it thinks for a while and then gives a blank screen). I'd say, that your curl-request might be trying to load a big amount of data, and that your PHP-configuration has a cap at 128mb (or something).
I'd check the PHPinfo for these two values:
max_input_vars
memory_limit
To see if either of them are suspiciously low.
Turns out my hoster is blocking all outgoing traffic to implicit IP's and ports other than 80 and 443. Cancelled my subscription and taking a decent provider now. Thanks for the help
According to the description of the Google Custom Search API you can invoke it using the GET verb of the REST interface, like with the example:
GET https://www.googleapis.com/customsearch/v1?key=INSERT-YOUR-KEY&cx=017576662512468239146:omuauf_lfve&q=lectures
I setup my API key and custom search engine, and when pasted my test query directly on my browser it worked fine, and I got the JSON file displayed to me.
Then I tried to invoke the API from my PHP code by using:
$json = file_get_contents("$url") or die("failed");
Where $url was the same one that worked on the browser, but my PHP code was dying when trying to open it.
After that I tried with curl, and it worked. The code was this:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$body = curl_exec($ch);
Questions:
How come file_get_contents() didn't work and curl did?
Could I use fsocket for this as well?
Question 1:
At first you should check ini setting allow_url_fopen, AFAIK this is the only reason why file_get_contents() shouldn't work. Also deprecated safe_mode may cause this.
Oh, based on your comment, you have to add http:// to URL when using with file system functions, it's a wrapper that tells php that you need to use http request, without it function thinks you require to open ./google.com (the same as google.txt).
Question 2:
Yes, you can build almost any cURL request with sockets.
My personal opinion is that you should stick with cURL because:
timeout settings
handles all possible HTTP states
easy and detailed configuration (there is no need for detailed knowledge of HTTP headers)
file_get_contents probably will rewrite your request after getting the IP, obtaining the same thing as:
file_get_contents("xxx.yyy.www.zzz/app1",...)
Many servers will deny you access if you go through IP addressing in the request.
With cURL this problem doesn't exists. It resolves the hostname leaving the request as you set it, so the server is not rude in response.
This could be the "cause", too..
1) Why are you using the quotes when calling file_get_contents?
2) As it was mentioned in the comment, file_get_contents requires allow_url_fopen to be enabled on your php.ini.
3) You could use fsockopen, but you would have to handle HTTP requests/responses manually, which would be to reinvent the wheel when you have cURL. The same goes for socket_create.
4) Regarding the title of this question: cURL can be more customizable and useful to work with complex HTTP transactions than file_get_contents. Though, it should be mentioned, that working with stream contexts allows you to make a lot of settings for your file_get_contents calls. However, I think cURL is still more complete since it gives you, for instance, the possibility of working with multiple parallel handlers.
I'm using Eclipse and XDebug to develop a PHP application that relies on web services.
I have test pages that consume my services in 2 ways: AJAX (using jQuery) and cURL.
I add breakpoints to my service page and launch the debugger. When I call the the service from AJAX, execution stops nicely at the breakpoint, and I get my variables, step-by-step control etc.
But when I call the service using cURL (i.e. from within a PHP page), the breakpoints fail to function. Even if I turn on the "Break at first line" debugger option, I cannot get the execution to stop when using cURL.
Is it a debugger behavior? Do I need to add a hearder to my cURL calls? Alter the URL? Or is it an XDebug limitation?
Thanks for your time and effort,
Guy
I can't comment yet, so I post this as an answer.
Can you debug more than one AJAX request in one session?
Was your debug session still running in Eclipse when you tried to debug using cURL?
Description on how it works for me:
Start debug session with a simple debug.php file that contains only a <?php and nothing else. It stops on the first line, you "continue" it and it finishes execution.
Now request the script using cURL (or another browser) adding ?XDEBUG_SESSION_START=ECLIPSE_DBGP to its path (I even think this addition is optional)
Your script should show up in the debug view stopped at the first line
Hope ths helps.
Here is tip on how to trigger Xdebugger client from Curl without browser:
1- From command line:
curl -H "Cookie: XDEBUG_SESSION=1" http://YOUR-SITE.com/your-script.php
2- From PHP
<?php
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL, 'http://YOUR-SITE.com/your-script.php');
curl_setopt ($ch, CURLOPT_COOKIE, 'XDEBUG_SESSION=1');
curl_exec ($ch);
?>
So it doesn't matter if you attach "XDEBUG_SESSION=1" to CURL URL, but what is necessary is to send a proper cookie together with request.
I know this is a pretty old thread, but I thought I'd post my experience for others that may come across it, like I did, with the same problem. What I discovered is that, if you are debugging remotely (which I always do), there are a couple settings you have to change in php.ini to make this work. Here are the ones that worked for me:
xdebug.remote_connect_back = false
xdebug.remote_host = {client host name or IP}
The first setting is normally "true," and tells xdebug to look for the client at the same IP address where the HTTP request originated. In this case however, the request is coming from the server, so that won't work. Instead you must use the second setting to tell xdebug where to find the client. Hope this helps save somebody a little time!
To trigger the debugger the simplest solution is to use the cookie approach -b XDEBUG_SESSION=ECLIPSE_DBGP worked for me on eclipse, see below:
curl -H 'Content-type: application/json' \
-b XDEBUG_SESSION="ECLIPSE_DBGP" \
-X POST \
-d '{"uid":200, "message":"asdsad","message_type":1}'
http://daxuebao.local:8083/api/message/send
When you are debugging the Ajax request, that one is sent by the browser, in the same navigation context as the other (non-Ajax) requests -- which is why it works fine.
The request sent by curl is in another, different, context -- and I'm not sure you can hook the debugger into that... But, maybe...
First of all, here's an information that might prove helpful, quoting the Xdebug's documentation :
Xdebug contains functionality to keep
track of a debug session when started
through a browser: cookies. This works
like this:
When the URL variable XDEBUG_SESSION_START=name is
appended to an URL Xdebug emits a
cookie with the name
"XDEBUG_SESSION" and as value the
value of the XDEBUG_SESSION_START
URL parameter.
When there is a GET (or POST) variable XDEBUG_SESSION_START or the
XDEBUG_SESSION cookie is set, Xdebug
will try to connect to a debugclient.
To stop a debug session (and to destroy the cookie) simply add the URL
parameter XDEBUG_SESSION_STOP.
Xdebug will then no longer try to make
a connection to the debugclient.
Maybe it might work if you set that cookie "by hand", sending it allong the curl request...
I suppose you'd first have to get its value, as set by Xdebug at the beginning of the debugging session -- re-using the cookie you have in your browser should be possible, though.
Note : I've never tried this -- if you try, and it works, could you please confirm it worked ?
I ran into this same exact issue. I solved it by turning the auto-start feature off in php.ini:
xdebug.remote_autostart = 0
and then adding the API key to the webservice URL that my webservice client calls:
?XDEBUG_SESSION_START=<your API key here>
and I'm not sure if this matters, but I entered the API key into my debugger (MacGDBp). Now the debugger fires up only when the webervice server-side script is called, not when the client is started.
Hope this helps.
I have a php script, called from a web page (server is Apache debian 6.03), which does a GET and a POST both using curl. The GET is fine. The POST fails if php curl goes directly to the network but works fine if I use charles as a proxy. (Haven't tried other proxies.)
In particular, if I add
curl_setopt($ch, CURLOPT_PROXY, "localhost:8888" );
to my script (with charles runningon 8888) it succeeds. Otherwise I get:
"HTTP/1.1 400 Bad Request".
Any ideas greatly appreciated.
Oops. My script used cookies in the post and there was white space at the beginning of the cookie string which I constructed. Adding a 'trim' fixed the problem.
Sorry.
I'm attempting to use curl inside php to grab a page from my own web server. The page is pretty simple, just has some plain text output. However, it returns 'null'. I can successfully retrieve other pages on other domains and on my own server with it. I can see it in the browser just fine, and I can grab it with command line wget just fine, it's just that when I try to grab that one particular page with curl, it simply comes up null. We can't use file_get_contents because our host has it disabled.
Why in the world would this be different behavior be happening?
Found the issue. I was putting my url someplace that was not in curl_init(), and that place was truncating the query string. Once I moved it back to curl_init, it worked.
Try setting curl's user agent. Sometimes hosts will block "bots" by blocking things like wget or curl - but usually they do this just by examining the user agent.
You should check the output of curl_error() and also take a look at your logfiles for the http server.