Use http header ETag caching for all static content.

[StefanOberhumer]

Using the md5sum as ETag http header value should enable caching on all static http content.

[tbnobody]

To be honest I am not yet sure if it's worth to generate the MD5 hash for this files on every request instead of just deliver some kilo bytes.

[StefanOberhumer]

To be honest I am not yet sure if it's worth to generate the MD5 hash for this files on every request instead of just deliver some kilo bytes.

You have to count also the workload transferring "some kilo bytes" via network esp if you reach the MTU limit (~1500 bytes) and the transfer gets split into multiple packages.

I came across the problem as I flashed a self compiled firmware without made a commit into git before.
So the ETag in the http header was the same as the previos firmware used because the GIT-Hash was not changed.

My questions were:
How can I prevent this mistake?
Why I'm forced to do first a commit?
Can't the Etag http header not being used on all static content?

First I created a python script generating the SHA256 sums of the embedded files in the build step and add them as *.c files and using those pre-generated SHA256 sums as ETag values. (like: const char *xxxx_sha256sum = "12345...."; )
(I don't wanted do adapt the BUILD_FLAGS like you do in pio-scripts/auto_firmware_version.py as changing the BUILD_FLAGS leads into a fully recompilation of the whole project)
With that change the firmware increased so much (as far as I remember about 900 bytes) :-(
Then I tried the "on the chip" available MD5Builder() which seemd to me to be the best solution.
The ETag header currently gets only validated for the app/app.js.gz file.
So having the EtagValidateAndRespond() function available I use it on all static content.

Why I think this PR should be added:
1.) The amount of data on the network may be getting reduced (Transferring "some kilo bytes" need resources and more time than not transferring them)
2.) Prevent any human error (automatic use a ETag value based on the content)
3.) I think loading the webpage getting faster

Btw:
For the small files (/ (386 bytes), favicon.png (4590 bytes), favicon.png (3262 bytes)) the MD5 sum generation needs about 0-1 ms.
For the app/app.js file (~180000 bytes) MD5 sum generation needs about 9-10 ms.
I've tried to measure the network transfer times of the files but the timings were so unstable (TTFB was between 12 and 40ms regardless this PR or not)

[tbnobody]

Have merged it locally. Works great till now. Will be included in the next release.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.