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.