Microchip AVR-IoT question: How to correctly format a POST request

It appears the HttpClient library they provide is too simple to allow for this - you are configuring the headers on a POST request and not the post body. The code itself is pretty clear - if you examine http_client.h, you will find it only supports the following functions (comments removed):

#ifndef HTTP_CLIENT_H
#define HTTP_CLIENT_H

#include <Arduino.h>
#include <stdint.h>

typedef struct {
    uint16_t status_code;
    uint32_t data_size;
} HttpResponse;

class HttpClientClass {

  private:
    HttpClientClass(){};

  public:
    static HttpClientClass &instance(void) {
        static HttpClientClass instance;
        return instance;
    }

    enum StatusCodes {
        STATUS_OK = 200,
        STATUS_NOT_FOUND = 404,
        STATUS_INTERNAL_SERVER_ERROR = 500,
    };

    bool configure(const char *host, const uint16_t port, const bool enable_tls);

    HttpResponse post(const char *endpoint,
                  const uint8_t *buffer,
                  const uint32_t buffer_size);

    HttpResponse post(const char *endpoint, const char *messsage);

    HttpResponse put(const char *endpoint,
                 const uint8_t *buffer,
                 const uint32_t buffer_size);

    HttpResponse put(const char *endpoint, const char *message);

    HttpResponse get(const char *endpoint);

    HttpResponse head(const char *endpoint);

    HttpResponse del(const char *endpoint);

    int16_t readBody(char *buffer, const uint32_t buffer_size);

    String readBody(const uint32_t size = 256);
};

extern HttpClientClass HttpClient;

#endif

As a result, there is no way, using the HttpClient library at present, to actually send custom headers as it just doesn't accept them in the function.

The modem itself does support using custom headers on HTTP/S requests under very specific commands - notably AT+SQNHTTPQRY which supports an extra_header_line argument up to 1500 bytes (not sure if you can tack on \r\n to break that up into a few extra ones) but only for GET, HEAD or DELETE. This is not supported by AT+SQNFGET or ST+SQNFGETDATA. [EDIT - see my follow-up comment regarding POST - there are commands that support it on the modem side.]

I can't copy the actual AT command data as the command reference may be under NDA (I obtained it as such), but an open copy seems to be available at Microchip - https://iot.microchip.com/docs/assets/files/ATCommandsLR8.0-NoCopyright-f9315d856c8b84593a1cf8391b904c36.pdf on Page 76. If you could change the method to GET, then some library modification may make it work.

The only other option is similar to your previous code by using AT+SQNSD to do a raw socket connection and "spew" the request directly into the socket, but it will require an AT+SQNSSCFG for TLS security after the socket comes up which suggests it needs to be done asynchronously followed by an ATO to drop into data mode. Of course, working directly with AT commands with the module is not something that has been clearly documented at this time and while sequans_controller may help, it also isn't something that's clearly documented (especially handling unsolicited AT response codes in asynchronous set-up mode).

Unfortunately, there are no easy answers for this one ... but you can always play with AT command sequences by loading the UART Bridge firmware (https://iot.microchip.com/docs/arduino/debugging/overview) and opening a terminal emulator (e.g. Arduino's Serial Monitor) and hand-entering command sequences until it seems to do what you want. At least you can debug the modem commands this way.

- Gough

It appears the HttpClient library they provide is too simple to allow for this - you are configuring the headers on a POST request and not the post body. The code itself is pretty clear - if you examine http_client.h, you will find it only supports the following functions (comments removed):

#ifndef HTTP_CLIENT_H
#define HTTP_CLIENT_H

#include <Arduino.h>
#include <stdint.h>

typedef struct {
    uint16_t status_code;
    uint32_t data_size;
} HttpResponse;

class HttpClientClass {

  private:
    HttpClientClass(){};

  public:
    static HttpClientClass &instance(void) {
        static HttpClientClass instance;
        return instance;
    }

    enum StatusCodes {
        STATUS_OK = 200,
        STATUS_NOT_FOUND = 404,
        STATUS_INTERNAL_SERVER_ERROR = 500,
    };

    bool configure(const char *host, const uint16_t port, const bool enable_tls);

    HttpResponse post(const char *endpoint,
                  const uint8_t *buffer,
                  const uint32_t buffer_size);

    HttpResponse post(const char *endpoint, const char *messsage);

    HttpResponse put(const char *endpoint,
                 const uint8_t *buffer,
                 const uint32_t buffer_size);

    HttpResponse put(const char *endpoint, const char *message);

    HttpResponse get(const char *endpoint);

    HttpResponse head(const char *endpoint);

    HttpResponse del(const char *endpoint);

    int16_t readBody(char *buffer, const uint32_t buffer_size);

    String readBody(const uint32_t size = 256);
};

extern HttpClientClass HttpClient;

#endif

As a result, there is no way, using the HttpClient library at present, to actually send custom headers as it just doesn't accept them in the function.

The modem itself does support using custom headers on HTTP/S requests under very specific commands - notably AT+SQNHTTPQRY which supports an extra_header_line argument up to 1500 bytes (not sure if you can tack on \r\n to break that up into a few extra ones) but only for GET, HEAD or DELETE. This is not supported by AT+SQNFGET or ST+SQNFGETDATA. [EDIT - see my follow-up comment regarding POST - there are commands that support it on the modem side.]

I can't copy the actual AT command data as the command reference may be under NDA (I obtained it as such), but an open copy seems to be available at Microchip - https://iot.microchip.com/docs/assets/files/ATCommandsLR8.0-NoCopyright-f9315d856c8b84593a1cf8391b904c36.pdf on Page 76. If you could change the method to GET, then some library modification may make it work.

The only other option is similar to your previous code by using AT+SQNSD to do a raw socket connection and "spew" the request directly into the socket, but it will require an AT+SQNSSCFG for TLS security after the socket comes up which suggests it needs to be done asynchronously followed by an ATO to drop into data mode. Of course, working directly with AT commands with the module is not something that has been clearly documented at this time and while sequans_controller may help, it also isn't something that's clearly documented (especially handling unsolicited AT response codes in asynchronous set-up mode).

Unfortunately, there are no easy answers for this one ... but you can always play with AT command sequences by loading the UART Bridge firmware (https://iot.microchip.com/docs/arduino/debugging/overview) and opening a terminal emulator (e.g. Arduino's Serial Monitor) and hand-entering command sequences until it seems to do what you want. At least you can debug the modem commands this way.

- Gough