fhessel
Enabling Usage of the Library in ESP-IDF
I am interested in using your webserver sourcecode. But I would need two things:
- use your code in combination with esp-idf (not Arduino)
- use websocket with ssl enabled
For 1. I found already that it is possilbe to copy the arduino sources into a component directory - then your sources compile without error. But I would prefer to avoid the Arduino code. For 2. I could try to help to implement that - but I would need some hints on how your sources work.
Can you give me some helpful hints?
Kind regards Lothar
Hi Lothar,
First: Using the code in esp-idf I only have experience in programming the ESP32 using the Arduino layer on top of the esp-idf, so I have a bit of a hard time to estimate each and every step that may be required to convert the library to be usable with plain esp-idf. I think we need to consider the following dependencies:
- Handling of sockets etc., uses mostly the lwip implementation of the esp-idf
- TLS is done using the OpenSSL implementation of esp-idf, so you should be fine here.
- Data types may be defined through Arduino.h and may differ if you do not longer include that header file. This header has to be removed and maybe the types have to be replaced.
- The example scripts uses the Arduino Core WiFi Library to set everything up. Should be no problem for you if you use the esp32_https_server API directly.
So from my perspective it should not be too much work, but I'm afraid that I cannot help you with it because I would need to spent some time to get to know plain esp-idf better before.
Second: Websocket As mentioned in the repository's readme file, I originally planned to include websocket support in the library. The reason why that's not the case yet is, that I currently did not need the feature any longer personally so I did not priortize it that much. Basically the library works like this:
- The HTTPSServer is responsible for accepting connections on the server socket. Each connection gets an HTTPSConnection instance which is created by the server.
- The HTTPSConnection is basically a state machine (you'll find the code for each state here and an ascii drawing here). So first the request line is parsed to get the method and URL, then it parses the headers and then it gets to the request body. For standard HTTP requests, this data is passed to one of the handler function that can be defined by the programmer using the libraray.
- Once the handler function returns, the server checks if the connection can be "kept-alive" and then returns to the initial state (or the connection will be terminated).
- Request handling is done in the loop() function of the server, which will call the loop() function of active connections, respectively.
So if you wanted to enable websockets, you would need to check the header values in state HEADERS_FINISHED, and check if the client requested an Upgrade: websocket. Then, instead of processing the body and transitioning to state BODY_FINISHED, you would send the appropriate headers, transition to state WEBSOCKET and implement the websocket processing there. I would suggest to define a second type of handler function for this, similar to the request handler function, but with access to the raw socket.
So there is no detailed concept about it yet, but that's the way I planned doing this. I'm a bit short on time at the moment, so it may take some time before I could have a look at it by myself. If you want to start working on that feature and you face any questions/issues/problems, feel free to ask, I'll do my best to respond quickly.
One more thing: Would it be okay for you to split this issue apart in separate issues for esp-idf and websockets? I think that would be more clearly.
Best regards Frank
Hello Frank,
thank you for your long and quite comprehensive answer. Sure we can split this thread in two. Can I do it or do you prefer to do it? If I shall do it; how to do that? Just open another thread and change the tiltle of this one?
Today I already studied your sources. I think the transition to esp-idf should not be too difficult. Maybe it makes more sense to do this after the implementation of the websocket connection.
Unfortunately I found another issue for which I will open another thread.
Best regards Lothar
I split this ticket apart, so the web socket part can now be discussed/tracked under issue #13.