Skip to content
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

Endless loop on HTTPConnection::readLine #109

Open
erosinnocenti opened this issue Jan 13, 2021 · 7 comments
Open

Endless loop on HTTPConnection::readLine #109

erosinnocenti opened this issue Jan 13, 2021 · 7 comments
Labels

Comments

@erosinnocenti
Copy link

erosinnocenti commented Jan 13, 2021

Hello,
I'm using ESP32 Https Server on a WROOM-32 board.
I created a ResourceNode which serves an html page using GET method.
If I connect to that page using Chrome or Firefox from my PC it works without any problems.

The frontend for this project is managed by an Android application that connects to the ESP32 server through WiFi, using the WebView component.
Unfortunately, when the WebView component loads the page, the HTTP server hangs without logging anything.

If I turn on the debug log, I can see the headers coming in, but the "[HTTPS:D] Headers finished, FID=60" message doesn't show up and the HTTP server stalls in a not responding state.

After some debugging I found out a possible endless loop at this point:

It seems that if the last char is "\r" and the condition at line 295 is not met, then an endless while loop occurs because _bufferProcessed will not be incremented.

I simply incremented the _bufferProcessed variable after line 306 in order to fix my problem.
I just wanted to make you aware of this, just in case you want to fix it in the next releases.

Thanks and congratulations for this excellent project!

@bulrog95
Copy link

Hello,
I can confirm the same bug found in a javascript redirect during page load, but increment doesn't work for me , i have added this to correct the server freeze:
image

Thanks @erosinnocenti for this issue, i have gain many time in this bug ,
and it's true esp32_https_server is an excellent https server!

@fhessel fhessel added the bug label Jan 23, 2021
@fhessel
Copy link
Owner

fhessel commented Jan 23, 2021

Thank you both for your feedback. I'm still working on getting hardware integration tests running, I'll try to reproduce this issue in a test and then provide a fix for the next release.

@vvigilante
Copy link

Hello, I believe this pull request is the solution to the bug: #123

@vvigilante
Copy link

@fhessel , Hey Frank! Shall we proceed with merging my pull request? Please tell me if I can help somehow.

@Dilbert66
Copy link

I was getting consistent lockups accessing a page using the chrome Android browser due to this bug in the readline function. The increment fix took care of that issue. I still get handshake errors from that browser though on initial connection so that's a different issue. Desktop browsers such as IE and Chrome are fine. Wow, this repository hasnt been updated in years?
Is there a new ESP SSL library that people are using? There is not much out there that works.. This one at least accomplishes what I need (which includes ssl websockets).

@proddy
Copy link

proddy commented Nov 19, 2021

Is there a new ESP SSL library that people are using? There is not much out there that works.. This one at least accomplishes what I need (which includes ssl websockets).

I've been looking for one too for a long while now and was hoping to switch over to this library - but was put off by its inactivity. I'm still using ESPAsyncWebServer (non SSL) and although it has its problems, there's a lively community (although somewhat negative) and always someone that's managed to hack around its oddities.

@KaloNK
Copy link

KaloNK commented Nov 29, 2021

Same here, so i have decided to fork this library ( https://github.com/KaloNK/esp32_https_server ) and at least merge some pending pull requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants