I originally added it to my Arduino IDE ESP8266 project. For test purposes the two library files httpsRedirect.h and httpsRedirect.cpp were copied to the project directory and included the .h file in my project with:
#include "HTTPSRedirect.h"
I realised that I will need more pins for my project so I then set about porting it to the ESP32. Porting the code was no problem, but I did problems running it on the ESP32. The initial suspect was mbedtls and a possible tweak appeared to be required. This was not possible in the Arduino IDE, so a couple of days ago the project was imported into vscode+PlatformIO.
This thread came about as a result of that step. However, last night I decided to re-write the code without using the httpsRedirect library, using direct calls to WiFiClientSecure instead. I have spent quite a bit more time completing this today and it seems to have been worth it as it made possible to see what was happening “behind the scenes” in the httpsRedirect library and has led me to what I think is the underlying problem.
I don’t know whether mbedtls is involved or not, but the ESP32 seems to be very unreliable when making WiFi connections to the Internet. Usually the first connection fails, but the 2nd or 3rd succeeds. The problem is that although the project code performed up to 3 re-tries for the initial connection, the library does not attempt to re-try the subsequent re-directed connection so it just fails. There is no problem with running it on the ESP8266, but on the ESP32, WiFiClientSecure seems to fail almost every time on the 1st attempt.
The underlying problem seems to be the unreliability of the ESP32. My current code re-tries both connections up to three times and eventually succeeds, although I am not particularly happy with such a state of things.
Since I had already logged and issue with the author of the httpsRedirect library regarding the problem, I have updated the logged issue with my findings.
Incidentally, I had already noticed that the ESP32 is very unreliable when doing NTP requests. A generous amount of re-tries and timeout intervals seems to enable one to work around the problem, but again its not entirely satisfactory. I expect that the NTP client uses the same underlying WiFiClient class to do its work but I hadn’t really made the connection until just now.
The question is why WiFiSecureClient/WiFiClient on the ESP32 so unreliable? Is it a problem with this particular ESP devkit board, the ESP12E firmware code, or ESP32s in general? Could it be the fact that I am using client.setInsecure() ? I don’t know. My experiment has shown me that I don’t need to use the httpsRedirect library and I can work around the problem suffering some delays, but as for fixing the underlying problem, I have no idea at present. I did see a video from Ralph S Bacon where he had problems with the ESP32 dropping connections and his research led him to identify a problem with early ESP firmware, but this board I am currently using is a recent purchase. I have an older one from around 3 years ago which I also tried with the same result.