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.
Related
I have some PHP code that calls a web service. It works perfectly when running on my local machine, but when I try to run it on the remote server (where it will ultimately reside), I get the following error:
Warning: simplexml_load_file(http://XXXXXXXXX:8080/symws/rest/standard/searchCatalog?clientID=StorageClient&term1=ocm00576702): failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request
in /var/www/ShoppingCart/storage_request_button.php on line 42
My local machine is running OSX; the server is running debian linux.
Any idea what could be causing this different behavior? Is there another package I need to install on the server?
UPDATE:
While putting the URL in a browser works fine, when I try to wget the URL from the linux server, I get the 400 error. The server URL is accessing is also debian linux. There's no firewall on the server. I've never had to configure that server to allow access to it from anywhere else.
You could try to supress errors as this question mentions to get rid of the status = 400. Perhaps with simplexml_load_file('url', null, LIBXML_NOERROR);
If it still doesnt work, there are a lot of things that can go wrong. simplexml_load_file doesnt have a lot of options to debug. You could try using curl.
<?php
// make request
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://XXXXXXXXX:8080/symws/rest/standard/searchCatalog?clientID=StorageClient&term1=ocm00576702");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($ch);
// handle error; error output
if(curl_getinfo($ch, CURLINFO_HTTP_CODE) !== 200) {
var_dump($output);
} else {
//load xml
$xml= simplexml_load_string($output);
}
curl_close($ch);
if (empty($xml)) {
echo 'Something went wrong';
exit;
}
?>
UPDATE:
Give this a try please and see if you get some info back:
<?php
$content = file_get_contents('http://XXXXXXXXX:8080/symws/rest/standard/searchCatalog?clientID=StorageClient&term1=ocm00576702');
var_dump($http_response_header);
?>
My guess is that your URL is malformed.
Here's what the 400 code means.
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications."
Well, I don't think anyone was going to be able to help me with this one. Here's what it was: The server that was sending the request, storagews, was originally cloned from the server receiving the request, sws. Because of this, in storagews's etc/hosts file, the hostname "sws" was resolving to localhost. So it was trying to send the request to itself. It was raj_nt's comment that clued me in to this. If you want to make an answer, I'll give you the bounty.
Thanks for trying everyone!
checkout the request being sent by simplexml_load_file.
you could also try accessing the 'url' directly in the browser (assuming you are performing a GET request)
you also need to consider the server side. Your server might be throwing a response with a 400 code even though everything is working normal. It might also not programmed to accept the request you are sending.
I assume that file loads directly to Your browser. Check with CURL and spoof user-agent to one from Your browser. Try also to enable cookie feature.
here's some example: http://www.electrictoolbox.com/php-curl-user-agent/
$output = file_get_contents("http://www.canadapost.ca/cpc2/addrm/hh/current/indexa/caONu-e.asp");
var_dump($output);
HTTP 505 Status means the webserver does not support the HTTP version used by the client (in this case, your PHP program).
What version of PHP are you running, and what HTTP/Web package(s) are you using in your PHP program?
[edit...]
Some servers deliberately block some browsers -- your code may "look like" a browser that the server is configured to ignore. I would particularly check the user agent string that your code is passing along to the server.
Check in your PHP installation (php.ini file) if the allow_url_fopen is enabled.
If not, any calls to file_get_contents will fail.
It works fine for me.
That site could be blocking the server that you're using to access it.
When you run the URL from your browser, your own ISP is used to get the information and display in your browser. But when you run from PHP, the ISP of your web host is used to get the information, then it passes it back to you.
Maybe you can do this to check and see what kind of headers its returning for you?
$headers=get_headers("http://www.canadapost.ca/cpc2/addrm/hh/current/indexa/caONu-e.asp");
print_r($headers);
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'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.