-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTPClient connection unexpectedly closed by underlying WiFiClient #5379
Comments
@Jeroen88 can you please try to reproduce with normal WiFiClient instead of the secure one? |
@devyte that is somewhat complicated. My cloud server is set up not to accept insecure calls, and if I disable that my sensor network will fail to connect. Any test I could do on a secure connection? |
@devyte I created an insecure route on my cloud server and sent data repeatedly reusing the connection with a normal WiFiClient without any problem! |
I'm wondering if the disconnect happens at WiFiClient level or below, or above at ssl level. It's entirely different places to look at. |
I will try... |
@devyte It is not my most beautiful code (quick and dirty) but this shows the same behavior, even without reusing the connection! It is on a public url, so you can try it yourself.
This gives the following output:
And this sequence is repeated |
@earlephilhower is this enough for you to make an assessment? |
I saw that I forgot to call https.end() at the end of the loop (just before delay()). I added it, but this does not make a difference. |
Debugging shows the problem clearly. Thanks, @d-a-v for adding the simple line.
This stems from what I believe to be a bad design choice, namely clearing all authentication options from the BSSL client object on a close. HTTPClient et. al. can no longer than use the client object after a |
Many objects now expect a WiFiClient* object to be passed to them and potentially re-used multiple times (HTTPClient, others). Clearing the authentication options on a ::stop means they can never reconnect. Remove the option clearing in ::stop Fixes esp8266#5379
Many objects now expect a WiFiClient* object to be passed to them and potentially re-used multiple times (HTTPClient, others). Clearing the authentication options on a ::stop means they can never reconnect. Remove the option clearing in ::stop Fixes #5379
@earlephilhower thnx for the PR, I will try it next weekend! |
@earlephilhower I can confirm reusing the connection is also fixed in my sketch. Thank you! |
Basic Infos
Platform
Settings in IDE
Problem Description
I use ESP8266HTTPClient to POST data to my NodeJS Express server. I ::setReuse(true) to keep the connection alive. Even if I check if the client is ::connected() before writing to the client, I get a HTTPC_ERROR_SEND_HEADER_FAILED or a HTTPC_ERROR_SEND_PAYLOAD_FAILED on the 'even' calls.
I already found out that the 'odd' calls succeed, because if the state is 'disconnected' the client reconnects automatically. I also found out that a work around is not using ::setReuse(true) at all. If I ::begin() every time, the data is posted without any issues.
I already checked that ESP8266HTTPClient is not disconnecting (_client->stop() is never called), so it must be the underlying _client disconnecting.
I am using WiFiClientSecureBearSSL for transport.
Until recently reusing the connection worked fine.
Maybe issue #5375 is related?
MCVE Sketch
The sketch is too big to add
Debug Messages
The text was updated successfully, but these errors were encountered: