-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ESP8266WebServerSecure: streamFile not correctly implemented #4544
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
Comments
Looks to be a very simple fix, just need to add the template and make is use _currentClientSecure instead of _currentClient to send the data. I'll throw something together tonight. |
Are you sure that this is enough? WifiClientSecure seems to be missing a |
You might be right, if the template doesn't compile when calling _currentClientSecure.write(stream) that'll need to be added to WiFiClientSecure as well. Nothing conceptually hard, I think. I'll definitely be sure to test your MCVE sketch! |
ESP8266WebServerSecure's streamFile was using the base class' method which did not use SSL encrypt before transmitting, leading to failure. Add a new template method and required support for WiFiClientSecure::write(Stream&) (using a local temp buffer since the SSL libs do not grok Arduino Streams at all). Fixes esp8266#4544
You were right, the write(Stream&) method wasn't there. It is now, in the PR. I tested your MCVE and it works fine, but if you could test your real app with it that would be a much better test. |
Thank you for this wonderful fast fix. My real app doesn't differ that much from the example, but both applications work fine with your pull request. For me, this problem is now fixed. Thanks for your time and keep on the good work. ;) Should I now close this issue or wait until it is merged? |
* Fix WebServerSecure streamFile() ESP8266WebServerSecure's streamFile was using the base class' method which did not use SSL encrypt before transmitting, leading to failure. Add a new template method and required support for WiFiClientSecure::write(Stream&) (using a local temp buffer since the SSL libs do not grok Arduino Streams at all). Fixes #4544 * Match ClientContext buffer and yield() behavior ClientContext sends out 256 bytes at a time and gives a yield after each chunk to ensure the WDT doesn't fire. Mimic that behavior in WiFiClientSecure::write(Stream&).
* Fix WebServerSecure streamFile() ESP8266WebServerSecure's streamFile was using the base class' method which did not use SSL encrypt before transmitting, leading to failure. Add a new template method and required support for WiFiClientSecure::write(Stream&) (using a local temp buffer since the SSL libs do not grok Arduino Streams at all). Fixes esp8266#4544 * Match ClientContext buffer and yield() behavior ClientContext sends out 256 bytes at a time and gives a yield after each chunk to ensure the WDT doesn't fire. Mimic that behavior in WiFiClientSecure::write(Stream&). (cherry picked from commit 42f824b)
Basic Infos
Platform
Settings in IDE
ESP8266WebServerSecure uses method
streamFile
of ESP8266WebServerESP8266WebServer and ESP8266WebServerSecure provide both the method
streamFile
which can stream a file to a client that connected to the webserver. However, this only works with unencrypted webservers based on ESP8266WebServer. Class ESP8266WebServerSecure doesn't overwrite the original method that is inherited from ESP8266WebServer. This obviously doesn't work with encrypted sockets, as it tries to send the date from the file a) to the standard socket from ESP8266WebServer and b) it doesn't encrypt the data.Changes need to be made in https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WebServer/src/ESP8266WebServerSecure.h and https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WebServer/src/ESP8266WebServerSecure.cpp which need to a) overwrite the standard streamFile method and b) provide a way to pass streams to the ssl library. Unfortunately, I'm not that experienced with C/C++ and cannot implement the changes on my own. That's the reason why I'm asking here to fix this issue.
The example creates a demo file "test.html" that is sent to the client and includes a 512 bit demo ssl certificate, which may get rejected when testing with recent browsers such as Google Chrome. Use command line tools like
wget
with the--no-check-certificate
option to connect to the server.A demo output from wget below shows that no data is send, which lets the request fail.
MCVE Sketch
wget Output
The text was updated successfully, but these errors were encountered: