Post WebRequest

Hello,

I am trying to send over some data to a php script and I am running into some problems/inconsistencies.

string url = "https://myServer.com/myProject/myPHP.php/?id=1";
WWW www = new WWW(url);

This ^^ works great. My php script gets data, I get data back. But I do not think it is a good idea to just send information like that?

If instead I do:

string url = "https://myServer.com/myProject/myPHP.php";
WWWForm form = new WWWForm();
form.AddField("id", "1");
WWW www = new WWW(url, form);

This does not work. My php script gets called, I receive data back, but my php script can not access the data I send.
I did try the same but using UnityWebRequest. It works the same - if I add "?id=1" it works, if I use WWWForms to add data, it does not work.

I'm pretty sure I used the second method a year or so back and it worked fine.
Can anyone tell me why this happens and how to fix it?
And I assume, writing in variables in the url does not benefit from any kind of obfuscation/encryption while using WWWForms does?

Using Unity 2022.2.15


Well, then your issue is most likely on the PHP side. How do you try to access the post variables? Also is your server / Php configured to actually populate the "$_POST" super global? We can't really help you here without the background info and what your PHP script actually does or how it reads the post arguments.

As Bunny83 said, hard to help without your php code snippet. I still have a clue for you :

In this code snippet, adding params to the url directly will add them to the query parameter of the http request

string url = "https://myServer.com/myProject/myPHP.php/?id=1";

But this code snippets, WWWForm is sent as an HTTP POST, that mean params should be added to the body parameter of the http request

string url = "https://myServer.com/myProject/myPHP.php";
WWWForm form = new WWWForm();
form.AddField("id", "1");
WWW www = new WWW(url, form);

You probably try to read QUERY parameters on your PHP side, that would explain why it’s working with snippet 1 and not snippet 2

Oh,
That explains everything. I was using $_GET instead of $_POST. That's not intuitive at all. Didn't touch php for a year and forgot this. It works with WWWForms now when I changed all my $_GET to $_POST. Thanks!

Though I do have an encryption question. If I just make sure to use https, all the encryption stuff is done automagically in the background, right? Do not need to manually fiddle with anything?


For SSL / TLS encryption your server needs a certificate. You can install a self-signed certificate, however browsers and most clients would reject it as it can not be verified. In browsers you can usually explicitly accept the risk, however the encryption state would be "yellow" as it can not be verified that the certificate actually belongs to your server. If there's a man-in-the-middle he could provide his own self-signed certificate and you could not tell the difference.

Usually "proper" SSL / TLS certificates are signed by an CA (certificate authority). Such certificates usually cost money. However since there's Let'sEncrypt you can create a proper certificate for your domain name through the certbot on your server. During this process Let's Encrypt makes sure your server is actually located / reachable under the specified domain name. Those certificates automatically expire after 3 month and have to be renewed regularly. Though this can be done with a cron job on your server. There are many tutorials how to setup and register a Let's Encrypt certificate. Certbot is also quite intelligent. If you use an apache2 webserver, it can actually update / add a config for apache to use the certificate it generated.

Note: It's usually possible to "ignore" the authenticity of the server certificate on the client. However this is a security risk. In most cases nobody can "monitor" your network traffic. The major risks are man in the middle attacks and ignoring the authenticity does completely break the security.


You do know the difference between a GET request and a POST request? Those two words are "literally" the first thing in the request ^^. URL query parameters are generally referred to as "get parameters" while information that is actually embedded in the body of the request (usually a http form that is URL encoded) is considered as post parameters. Though nowadays the usage of http forms has faded and most APIs use json, both in the request and the response. Though this of course depends on your application and your needs.

I got my server from one of the server renting websites and it does include an SSL certificate so I think I'm all good in that front (I did try explicitly saying http:// and my browser complained about security, but when I did https:// it was all good)

I never did much php and that was a while back so forgot the details :smile: My thought process now was that I POST stuff with Unity and then GET it in php :smile: Though it being name of location rather than action explains why it didn't work for me.

Thanks for the help!


Yes of course. If the server is already setup with a certificate there's nothing you have to do besides using https (port 443) instead of http (port 80).


I don't want you to come to the wrong conclusion, so let me expand a bit here. POST is actually a method and it's actually called "method" in the context of http. However keep in mind that the server is the one who essentially "executes" or processes the request. So on the server side you receive "posted" data because the client wanted to post data to your server. Conceptionally there's little difference between the different request methods. An http request looks pretty much the same. However the method essentially states what the client wants to do. A GET request's main goal is to just "get" data from the server. A get request can include parameters in the URL (as the search string) which are available to the php script as GET parameters.

HTTP is a really simple text based protocol. Each request essentially has 3 parts:

  • The request line which includes the method, the relative path / URL and the protocol version
  • A header section that immediately follows the request line. Each line is a new header. There can be an arbitrary amount of headers in a request. The header section is finished with an empty line (so two "\r\n" in a row)
  • Finally there's the body of the request. It can contain arbitrary data, though certain request types do not have a body, like GET for example.

Likewise a response looks almost the same. However the request line becomes the response line. It simply contains the response code (200 for "ok", 404 for "Not found", ...) as well as a descriptive text of the response code. So this is literally just "Ok" or "Not Found". A response can also include various headers (like Set-Cookie but also metadata like Content-Length). The body of a response contains the actual data that was requested. Of course certain request types also don't have a body (like HEAD). If you want to understand it a bit better, you can use the developer tools of your browser (chrome or firefox at least, but most modern browsers have something similar). There's a network tab where you can see every request this browser tab has made to a server. You can inspect the request and response headers as well as the posted and received data.

The overall structure of plain http is simple. Though there are several extensions which can make things more complicated (Keep alive, multipart requests, caching, cross-domain restrictions, ...). Though all in all it's relatively easy to debug as it's completely text based.

A quick note on PHP: When you request "a resource" on your server, your server simply returns the resource located at the specified relative path. That's how most http servers work. However from a technical point of view the actual path in the URL has not necessarily a direct link to an actual directory / folder on the server. However as I said, most servers work this way. When you "request" a php file (and php is properly installed and configured on the server), the server will actually call PHP and instead of returning the actual file to the client, it will return whatever PHP outputs. So the webserver simply hands the request to PHP and let it handle the request.