HELPDESK_WJ (Waijung)

Thank you for reaching us.
If you carefully look in to the Developer Tools in Chrome browser, it shows that the requested files are not served from the esp32 server except the html file.

It can be confirmed using the log data from the serial monitor.

If a file is successfully served, it will show that the headers are set and the response data is sent for the corresponding request. In this scenario, it shows only for the first request.

One of the reasons for this problem will be the incorrect file path or file is assigned to an incorrect request. In the attached simulink model, there are two issues in the get handler block configuration. First, the given request from request #2 and onwards are partial requests but " Compare whole request " option is checked. If this option is checked you have to state the full request. As an example, for the request #2, if the above option is checked, the comparing request should be "/assets/bootstrap/css/bootstrap.min.css". Otherwise above option should be unchecked.

Second is the file location. For this, the full file path is required not the folder path.
If you configure the get handler block as below from request #2 to 8, you can fix those problems.

We will add useful log messages for the http server block and fix the block mask appearance issue in future releases.
Please let us know if the problem still persists.

Thanks for your reply.
I started over again with an empty http get handler and leave the "compare whole request" unchecked.
When compiling and downloading the code into the esp32 module, the serial debug port shows up new error messages, namely 'unexpected token' when loading the index.html page.
You can also see that all header types are (re)set to 'html' for all different files, like bootstrap.min.js, jquery.min.js...

Is there any workaround possible to get the web page running as intended, including the background images.

Best regards,

Martin.

Hello Martin,

As a solution for this issue, please check " Compare whole request " for the request #1 because it is a complete request and from request #2 to 8 uncheck the "compare whole request". And check " Enable wildcard for this handler " , otherwise it will be required 8 get request handler blocks to handle the 8 requests.

I have attached the patch file for bugfix of the the block mask appearance issue. please replace the following patch file, esp32_http_server_callback.p at the location: " ...[ your path to waijung2 installation directory ]\waijung2_20.11b\waijung2\targets\esp32\src\blocks "

Thanks a lot,
This quick fix solves most of the annoying problems.
Now it's possible to open and edit the http get block, that saves a lot of retyping all needed data ;0))

But there is still a small bug.
When opening the index.html page that is running on the esp32, that loading process will never ends, it is trying to load the webpage forever.
When opening the same index.html page, directly from the SD card then loading will end after a few seconds and everything is working as intended.
How can I solve this 'forever loading' behavior.

The quick solution for this issue is to add a new request to the get request handler block. If you check in the Developer Tools in Chrome browser, it shows that there is a pending file in the client. That's the reason why the web page shows that it still loading.

If you add a new request as below, you can fix that issue.

Hi Chandima,
Thanks for your additional information.
After adding the "pending" file requests will result in an error free webpage finally.
This is a very clumsy http web server setup interface, comparing with the Waijung 1 blockset (stm32f4).
Waijung 1 blockset only needs a http webserver object and the complete webpage is displayed at the glance.

What if the http server get block needs more than 12 requests, can you combine more blocks to overcome this limitation?
Best regards,

Martin.