Closed henrygab closed 2 years ago
Thank you, this is something I've been meaning to do for a long time!
But, I can't get the web app to work. It's listing the FS contents in the serial monitor:
FS File: css, size: 0
FS File: edit.htm, size: 7887
FS File: favicon.ico, size: 4286
FS File: fonts, size: 0
FS File: images, size: 0
FS File: index.htm, size: 14578
FS File: js, size: 0
FS File: simple.htm, size: 2279
FS File: wifi.htm, size: 4190
But it will not serve any files. I've tried it with the data files gzipped and without.
Requests for /
return a 200 OK
response with Content-Type: application/octet-stream
, Content-Length: 0
, etc, and results in Chrome saving empty download
, download (1)
, etc files.
Requests for any other files, such as index.html, favicon.ico, etc, result in a 404 Not Found
response.
Most other things seem to be working fine. All the REST API calls, such as /all
, the firmware and filesystem updater at /update
, etc. But the static file serving does not. The file editor at /edit
lists the files, but they're missing the first letter in the name of each file, and selecting them results in 404 Not Found
errors:
Hmm... Definitely unexpected. Family emergency may limit me for a few days, but definitely unexpected and piqued my interest why that's happening.
I did verify the LED (default page) was working.... But didn't know (or test) all the endpoints. Sorry for not catching those issues!
I think I have a fix for the loss of the first character. Testing now.
Remove the substring(1)
is what I'm testing...
8cb78f7 seems to fix /edit
.
Not sure if support for directories was ever implemented (was hard-coded to false
). I wrote the fix, but then the directories disappeared, so I reverted to the hard-coded false
.
Thank you, this is something I've been meaning to do for a long time!
But, I can't get the web app to work. It's listing the FS contents in the serial monitor:
FS File: css, size: 0 FS File: edit.htm, size: 7887 FS File: favicon.ico, size: 4286 FS File: fonts, size: 0 FS File: images, size: 0 FS File: index.htm, size: 14578 FS File: js, size: 0 FS File: simple.htm, size: 2279 FS File: wifi.htm, size: 4190
But it will not serve any files. I've tried it with the data files gzipped and without.
Requests for
/
return a200 OK
response withContent-Type: application/octet-stream
,Content-Length: 0
, etc, and results in Chrome saving emptydownload
,download (1)
, etc files.Requests for any other files, such as index.html, favicon.ico, etc, result in a
404 Not Found
response.
Hi Guys,
I remember having had some issues as well when moving to LittleFS or even before. Its kinda hard to chase and trace now as I have a mix (mess) of several sources/projects and meanwhile also changed to AsyncWebserver...
What I see in difference is that in addition to webServer.serveStatic("/", MYFS, "/", "max-age=86400");
I do have:
server.on("/", HTTP_OPTIONS, []() {
server.send(200, "text/plain", "" );
});
server.serveStatic("/", LittleFS, "/", "max-age=86400");
Maybe this helps?
Regards, Toby
Btw: I did not yet manage to get the /edit to work with LittleFS (can only list files and content but without directories). But I did not did into that that much as I am not using this.
OK, disregard. The web app is working fine now, with no code changes, so I'm not sure what was wrong before.
The file editor was apparently already broken, and needs updated to the latest version of the FSBrowser example: https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WebServer/examples/FSBrowser
That can be done later, completely separate from this PR.
What I see in difference is that in addition to
webServer.serveStatic("/", MYFS, "/", "max-age=86400");
I do have:server.on("/", HTTP_OPTIONS, []() { server.send(200, "text/plain", "" ); }); server.serveStatic("/", LittleFS, "/", "max-age=86400");
@tobi01001 ... I just noticed this, and thought I'd call it out, in case it later surprises you (As it did me).
if you serve files using .serveStatic()
, the webserver will cache various information (I think file size was one thing). Thus, if you are editing the file, resulting in a larger file, and this is still the behavior, you will get corrupted (truncated) data from the webserver. The file on disk is fine, and will show up properly after reboot. Again, just thought I'd mention it because it surprised me at the time....
This PR does three things. Each section is expandable / collapsible:
Upload tool for LittleFS on ESP8266 (arduino IDE): https://github.com/earlephilhower/arduino-esp8266littlefs-plugin
Move `data` under sketch directory
I missed this in PR #208. The Arduino IDE requires that the web files be located in a subdirectory of the sketch. This restores the ability to upload the files from the IDE.Move from SPIFFS to LittleFS.
SPIFFS is deprecated. Building with warnings enabled will fill the build log with many warnings as to this fact. LittleFS is a drop-in replacement. Here's the difference is the binary sections between commit 0427421 and 7f39a83, using the Arduino IDE: Segment | SPIFFS Size | LittleFS Size | Difference | Notes ----------|------------:|--------------:|-----------:|-------- IROM | `405,840` | `399,836` | `-6,004` | IRAM | `28,368` | `28,444` | `+76` | Will within `32,768` (`16k` x 2) DATA | `1,312` | `1,312` | same | RODATA | `6,816` | `7,460` | `+644` | BSS | `30,464` | `30,464` | same | Basic testing was done on main branch.Move images from root to `images` subdir
This also moves a few image files from the root of the depot to an `images` subdirectory. These images were not used in the `readme.md`.Move scripts from root to `scripts` subdir
The `scripts`If this PR is approved, I intend to next provide PR for each other "active" branch, to merge these changes in each of those.