ESP32 Forum

I'm using the V3.0.2 release version of the IDF. But because I anticipate having to use certificates with HTTPS and I've been having issues with wifi and failed OTA's on crowded wifi I decided to try and use the esp_http_client and esp_https_ota in the newer IDF. I simply copied the two folders into a components folder in my project and it compiled/linked with no issues. In addition when I submitted it for testing the testers reported the OTA downloads has a better success rate.

We are not using certificates yet and I just want to note that if you comment out the tests for providing a certificate in esp_https_ota, the process works just fine as encrypted HTTPS connection.

So here's my question... Why is there a configuration item added to define CONFIG_ESP_HTTP_CLIENT_ENABLE_HTTPS? Simply using the library and passing a URL that contains HTTPS instead of HTTP will provide the info needed to answer that question. Using port 443 instead of 80 will do the same. In addition the esp_http_client_config_t contains an entry for "transport_type", which is either TCP or SSL.

John A

This is to reduce code size by eliminating https related features if https transport is not needed.

ESP_igrr wrote:This is to reduce code size by eliminating https related features if https transport is not needed.

OK, that makes some sense. Although it seems that by using the config parameters it could decide that at run time for each client, which might take less memory if not all connections use HTTPS.

Also now that I'm trying to use this for other then OTA, I'm wondering why it fails without a URL assigned. I have filled out all the other parameters that would override the URL. I'm providing host, port, transport, method, query string, etc..

I guess I can construct a URL that does all that instead. But it's not clear from the docs that a URL is required because it overrides the other parameters, which suggests that it's optional.

John A

I have the same issue. I thought i can use host, port and path instead url to build request but it seems does not work.

chegewara wrote:I have the same issue. I thought i can use host, port and path instead url to build request but it seems does not work.

Cool. Just wanted to confirm I'm not missing something. But from looking at the source it seems that there is no way around providing a URL. Not a big deal.

John A