load web files from filesystem

[ChrisVonFrosta]

is it possible to load "normal" formated styles.css or somthing like that from filesystem?

[s-hadinger]

You need to be more specific, otherwise the response is "it depends"

[s-hadinger]

Unfortunately there is no direct support for serving content stored in file-system. It should not be too hard to implement using simple Berry code. But I won't be able to explore in the short term.

[sfromis]

@s-hadinger AFAIK, there should be support for serving filesystem content, with #define UFILESYS_STATIC_SERVING and command UFSServe (btsimonh was sneaky with some changes #19014 b1cc87d )

Tasmota/tasmota/tasmota_xdrv_driver/xdrv_50_filesystem.ino

Lines 26 to 30 in 9d963ce

	// Enables serving of static files on /fs/
	// costs 1844 bytes of flash and 40 bytes of RAM
	// probably not useful on esp8266, but useful on esp32
	// You could serve a whole webapp from Tas itself.
	//#define UFILESYS_STATIC_SERVING

I wanted to try it out, but unfortunately, build fails

/tasmota/tasmota/tasmota_xdrv_driver/xdrv_50_filesystem.ino:1046:10: error: 'bool StaticRequestHandlerAuth::handle(WebServer&, HTTPMethod, String)' marked 'override', but does not override
 1046 |     bool handle(WebServer& server, HTTPMethod requestMethod, String requestUri) override {
      |          ^~~~~~

[mathieucarbou]

@sfromis : fyi you are overriding the wrong definition. If I open arduino main branch it is:

virtual bool handle(WebServer &server, HTTPMethod requestMethod, const String &requestUri)

[btsimonh]

@mathieucarbou - see fix in comments below.
I think since this was written (by me) things changed in the arduino code we use here. But even when the defn is correct, we then hit the linker error - see issue I raised in arduino libs that me-no-dev has att-ed you on.
We should be good with the fix below; I just can't actually test it at the moment.

[s-hadinger]

Indeed. I went past the signature change but the linker error is something else. I'm not home this weekend either so I can't test

[wjohn007]

A working UFILESYS_STATIC_SERVING would be really helpful.

The proposed solution with Berry only allows small files to be served,
as these must first be read completely by Berry and thus use up a lot of memory.

In the meantime, the attached FileServer class might help.
More information in the comments of the file.
FileServer.zip

I used that in the following application

[sfromis]

I think that it could also be feasible with redirects to links like what was used in the above.
http://192.168.170.120/ufsd?download=/pfeil.png
The webserver module has a redirect method for setting location and status 302.

That should avoid the path through Berry code, and still be workable with standard browser handling of relative URL for same-site references like /assets/pfeil.png, when the URL format with a query string is not workable.

[s-hadinger]

I looked at the UfsServe code. Unfortunately the code added by @gemu2015 does not work due to a C++ conflict when importing RequestHandlersImpl.h. Which means that using the native Arduino static server has the following limitations:

• no root file serving, i.e. requesting <prefix>/ will not work, and will require an explicit <prefix>/index.html
• authentication will not work either

I'm not sure it's worth it.

[joba-1]

Arduino header RequestHandlersImpl.h contains implementation that is compiled twice and generates a linker error for multiple declaration of the same functions.

Imo this is an arduino bug. Headers should only contain declarations, never definitions. Definitions need to be in a c/cpp file.

[btsimonh]

arduino bug

by design, much arduino library code is implemented in headers :(. This specific 'bug' was introduced after the original UFSSERVE code though...

[btsimonh]

Maybe they will fix it:
espressif/arduino-esp32#11054

[mathieucarbou]

FYI, I looked at the issue and this discussion (I implemented the middleware layer).

by design, much arduino library code is implemented in headers :(. This specific 'bug' was introduced after the original UFSSERVE code though...

RequestHandler.h RequestHandlersImpl.h are there since 2018 while #18859 since 2023.

Headers should only contain declarations, never definitions. Definitions need to be in a c/cpp file.

I disagree. Look at ArduinoJson and many other libs. Done correctly, it works. Splitting the declarations and definitions is just a way to avoid recompiling everything when a header changes.

About RequestHandlersImpl.h

RequestHandlersImpl.h is not to be used or extended: this is an implementation.

They decided to put the implementation in a header, which references external things, and this implementation is only included once from webserver.cpp. So this works and is ok in this specific use case. But nobody should ever point, include or extend this file!

RequestHandler.h is the one to use, and can be extended to create request handler, and do not forget to work by delegation and composition instead. Do not try to inherit existing implementations.

[sfromis]

Using the previously suggested workaround of a redirect, I found that I already now can have a binary file served directly from the file system, in a same-site URL friendly way like the URL http://mydevice/logo.png being matched by:

webserver.on("/logo.png", /-> webserver.redirect('/ufsd?download=/logo.png'))

As the image file was downloaded ok, serving a binary file did not seem to be a problem. The log shows a message of UFS: File '/logo.png' download

The downside is that the file will be provided as an attachment for download, instead of the client getting the data in a simple response, and that there are no options for setting Content-Type etc.

As I'd not expect this to work out across clients, I was wondering if it would be feasible with a tweak to simplify the response to not be wrapped as a download attachment? And maybe also to not need the setup via Berry webserver.on for each file.

Still, I was able to get the image to work in a web page, thus it is already now "somewhat workable".
<img src="http://mydevice/logo.png">
(The Chrome browser did warn about the redirect being insecure, instead of https)

[btsimonh]

Note that if/when the above suggested fix (https://github.com/btsimonh/Tasmota/tree/FixUFSSERVECompile) is tested and works, it's not a great implementation; more of a 'make it work again'.
See espressif/arduino-esp32#11054 (comment)
for better suggestions for next time someone has time to fully visit this, and 'future proof' it.
Thankyou to @mathieucarbou for the suggestions.

[Jason2866]

Why not disable completely until someone does it via Middleware support? Honestly I am not a fan of flicking code which will brake probably soon again.

[btsimonh]

It's not enabled in any std build. But that also means it's not generally tested on change. However it is a nice feature...