wp_remote_get or wp_remote_post (instead of curl())? WordPress
- SOLVED
For license activation I am currently using curl() directly in my plugin. For higher compatibility I would like to use WordPress HTTP API instead.
Currently on license check, the API endpoint is called with a post request sending some data ($querystring) about the plugin to the server where the validation is done:
$curl = curl_init();
...
curl_setopt($curl, CURLOPT_POSTFIELDS, $querystring);
...
$result= curl_exec($curl);
I already successfully tested it using WordPress HTTP API instead of curl():
$result = wp_remote_post(
$url,
array(
'sslverify' => false,
'timeout' => 15,
'body' => $querystring
)
);
works as well as
$result = wp_remote_get($url . '?' . $querystring,
array(
'sslverify' => false,
'timeout' => 15
)
);
Which function should be used for this and why? I've read that some methods in the WordPress HTTP API do not support sending in a body, so wp_remote_get is a safer? Is that true? Couldnt verify that.
I want to have highest compatibility as the plugin is used widely. Any other considerations to take into account here?
Thx!
Answers (1)
John Cotton answers:
The only difference between wp_remote_post and wp_remote_get is the HTTP method used for the call.
Otherwise they use the same internal api code.
Clearly a get adds query string fields whereas a post sets header values.
The [[LINK href="http://www.w3.org/Protocols/rfc2616/rfc2616.html"]]HTTP spec[[/LINK]] gives reasons why you should choose one over the other. Briefly it comes down to whether you are querying data (GET) or sending data to make a change (POST) (that's a very simplistic explanation but hopefully you get the idea).
If you are controlling both ends, then go for whichever makes more sense to you.
John Cotton comments:
PS - The WordPress HTTP API is likely (thought not certain) to be using curl since it's the first one to be tested for use.
However, it's good to use the API and it saves you doing a lot of code and also takes the pain away from checking availability of transport mechanisms.
Robert Seyfriedsberger comments:
thanks! the reason I started thinking about using the WordPress http API is that users might have defined a proxy in wp-config which would not get used if curl() is called directly.
Anyway as I am querying data (=send back string to plugin from server if the license key+parameters are valid), GET should be the preferred method I guess...
Robert Seyfriedsberger comments:
just a short follow-up question: could there be any side effects regarding the caching of the result? in the spec I read that this is possible with GET but not with POST
thx
John Cotton comments:
There could definitely be an issue with caching - there could be a proxy as you mention and you'd not even know it was a cached result.
The best way around that (assuming you always want a proper response) is to add some random value to the query.
Of course, if your server returns the correct headers with caching instructions you would limit any caching by external operations.
In theory a POST will not be cached but there's nothing to stop a server/application/OS ignoring the rules!
Robert Seyfriedsberger comments:
thx! I think I'd rather prefer POST because of this. Another issue could be that the GET requests adds all parameters - including license key - to the request URL and this info could be more easily logged with GET (POST requests aren't logged with all headers sent usually as far as I know)
John Cotton comments:
<blockquote>Another issue could be that the GET requests adds all parameters - including license key - to the request URL and this info could be more easily logged with GET (POST requests aren't logged with all headers sent usually as far as I know)</blockquote>
This is a call from the user's server rather than browser so it's not so readily seen anyway.
But don't convince yourself that the values are hidden - if they want to see them, they are captured relatively easily by someone in control of their server.
Robert Seyfriedsberger comments:
right. anyway: as the API can be accessed via https only: will the request info be visible in the logs of the users server? I just can't figure out why the user pointing me to this issue could send me the full details of the request (method, headers...) when the info was retrieved via https and curl... do you happen to know that too?
Robert Seyfriedsberger comments:
I am referring to this thread:
http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other
where a user also says:
The entire HTTP conversation is encrypted, the only visible portion of communication is on the TCP/IP layer (meaning the IP address and connection port information
John Cotton comments:
The TCP/IP packets are encrypted with HTTPS (though not the IP and routing information, otherwise routers and switches wouldn't know where to pass the packets on to).
But the preparation to initiate the call as made from the server (or browser) is not secured.
Try it yourself with debug tools in a browser like chrome. You will see just the same information being sent for the network call with https as with http.
It's only the transmission over the internet (ie beyond the machine's network card) that is secure.
Robert Seyfriedsberger comments:
thanks!