Sending HTTP requests with AT commands on the ESP32

Question

I'm trying to send AT commands to my ESP32* module and am not getting any response back. I need to perform a POST request that contains the username and password and other requests later on. I am not structuring these correctly and there is not a lot of good documentation for this.

NOTE: because I cannot share my complete url due to privacy I will use something with the same length ********connected.com:443

1. Send login information to ********connected.com/login (POST) body{"email":"myemail.ca", "password":"xxxxx"}

   • once I get the token I will make other requests.

2. get information regarding user profile ********connected.com/getRoutine ( GET) query param username="bob"

3. I really want to understand how these requests are structured so if someone can explain it to me elegantly that would be great!

Here is what I have tried..

AT
OK

AT+CIPSTART="TCP","********connected.com",443
CONNECT
OK

AT+CIPSEND=48
> "GET ********connected.com:443/getUsersOnline"
OK
>
Recv 48 bytes

SEND OK
CLOSED

REQUESTED POST REQUEST I HAVE USED

AT+CIPSEND=177 “POST \r Host: ********connected.com\r\n Accept: application/json\r\n Content-Length: 224r\n Content-Type: application/jsonr\n { "email":"myemail.com", "password":"myPassword" } “

Answer 1

There are actually several parts of your system that might be the cause of the malfunctioning:

1. The AT commands sent (it is not clear how you check for server responses. Responses could proviede clues about what's wrong)
2. The server side app seems to be a custom implementation that might have bugs as well
3. The POST request might be malformed

Let's focus on the last one.

POST are described in RFC 7231, and though it is an obscure description without examples, it makes one thing clear: there's not actually a well defined standard... because it is strictly application dependant!

I also quote the relevant part of this brilliant answer to an old SO question:

When receiving a POST request, you should always expect a "payload", or, in HTTP terms: a message body. The message body in itself is pretty useless, as there is no standard.

For this reason, all we can do is to build a POST request as accurate as possible and then to debug the system as a whole thing making sure that the request matches what expected by the server side application.

In order to do this, let's check another external link I found: POST request examples. We found this request:

POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2

Now let's compare this example to your request:

POST
Host: ********connected.com
Accept: application/json
Content-Length: 224
Content-Type: application/jsonr
{ "email":"myemail.com", "password":"myPassword" }

You are saying to the server that you want to pass a resource to an unspecified application (no path), and that this resource is 224 bytes long (wrong! Message body is shorter).

For these reasons, at least these things can be improved:

1. POST /path/invic18app.php HTTP/1.1 //The path to the application and HTTP version are missing
2. Content-Length: 48 //This must be the length of the message body, without the header. I also would write it as the last option, just before message body
3. Write TWO empty lines before message body, otherwise the server will interpret it as further (wrong) options

I hope this helps you, even if it is a tentative answer (I cannot try this request myself). But, again, you definitely need to sniff packets a TCP levels, in order to avoid debugging the server if you are not sure that data is actually received! If you cannot install Wireshark, also tcpdump will be ok.