Отправка HTTP-запросов с AT-командами на ESP32 - PullRequest
0 голосов
/ 03 ноября 2019

Я пытаюсь отправить AT-команды на мой модуль ESP32 * и не получаю никакого ответа. Мне нужно выполнить запрос POST, который содержит имя пользователя и пароль и другие запросы позже. Я их неправильно структурирую, и для этого не так много хорошей документации.

ПРИМЕЧАНИЕ: , поскольку я не могу поделиться своим полным URL-адресом из-за конфиденциальности, я буду использовать что-то с такой же длиной******** connected.com:443

  1. Отправить информацию для входа в ******** connected.com/login (POST) body {"email": "myemail.ca", "password": "xxxxx"}

    • как только я получу токен, я сделаю другие запросы.
  2. получить информацию о профиле пользователя ******** connected.com/getRoutine (GET) запрос param username = "bob"

  3. Я очень хочу понять, как эти запросы структурированытак что если кто-то сможет мне это элегантно объяснить, это было бы здорово!

Вот что я попробовал ..

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

ЗАПРОШЕНО ЗАПРОС ЗАПРОСА Я ИСПОЛЬЗУЛ

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" } “

1 Ответ

1 голос
/ 07 ноября 2019

Существует несколько частей вашей системы, которые могут быть причиной неисправности:

  1. Отправленные AT-команды (неясно, как вы проверяете ответы сервера. Ответы могут дать подсказки очто не так)
  2. Приложение на стороне сервера, по-видимому, является пользовательской реализацией, в которой также могут быть ошибки
  3. Возможно, запрос POST некорректен

Давайте сосредоточимся напоследний.

POST описаны в RFC 7231 , и хотя это неясное описание без примеров, оно ясно дает понять: на самом деле нет четко определенногостандартный ... потому что это строго зависит от приложения!

Я также цитирую соответствующую часть этого блестящего ответа на старый SO вопрос :

При полученииPOST-запрос, вы всегда должны ожидать «полезную нагрузку», или, в терминах HTTP: тело сообщения. Тело сообщения само по себе довольно бесполезно, так как нет стандартного .

По этой причине все, что мы можем сделать, - это создать запрос POST как можно более точным, а затемчтобы отладить систему в целом, убедившись, что запрос соответствует ожидаемому приложению на стороне сервера.

Для этого давайте проверим другую найденную мной внешнюю ссылку: Примеры запросов POST . Мы нашли этот запрос:

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

field1=value1&field2=value2

Теперь давайте сравним этот пример с вашим запросом:

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

Вы говорите серверу, что хотите передать ресурс в неуказанное приложение (без пути), и что этот ресурс имеет длину 224 байта (неправильно! Тело сообщения короче).

По этим причинам, по крайней мере, эти вещи могут быть улучшены:

  1. POST / path / invic18app.php HTTP / 1.1 // Отсутствуют путь к приложению и версия HTTP
  2. Длина содержимого: 48 // Это должна быть длина тела сообщения без заголовка. Я также написал бы это как последний вариант, непосредственно перед телом сообщения
  3. Напишите две пустые строки перед телом сообщения, в противном случае сервер будет интерпретировать это как дальнейшие (неправильные) опции

Надеюсь, это поможет вам, даже если это предварительный ответ (я не могу попробовать этот запрос самостоятельно). Но, опять же, вам определенно нужно прослушивать пакеты уровней TCP, чтобы избежать отладки сервера, если вы не уверены, что данные действительно получены! Если вы не можете установить Wireshark, все равно tcpdump будет в порядке.

...