Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:18
    dok-net synchronize #6804
  • 19:55
    dok-net synchronize #6047
  • 19:51
    dok-net synchronize #6902
  • 19:50
    dok-net synchronize #6782
  • 19:47
    dok-net synchronize #6857
  • 17:56
    devyte labeled #6898
  • 17:56
    devyte labeled #6898
  • 17:56
    devyte milestoned #6898
  • 17:53
    devyte synchronize #6898
  • 17:53
    devyte closed #6894
  • 17:52

    devyte on master

    fix for #6904: NodeMCU v1.0 boa… (compare)

  • 17:51
    devyte closed #6904
  • 17:51
    devyte closed #6905
  • 17:51
    devyte edited #6905
  • 17:50
    devyte edited #6905
  • 17:09
    d-a-v closed #6901
  • 15:57
    erdemuncuoglu review_requested #6905
  • 15:31
  • 15:09
    erdemuncuoglu opened #6905
Me No Dev
@me-no-dev
in any way and in any handler you should always respond to each request in some way
dragon-engineer
@dragon-engineer
yes definitely, that NotFound handler was your suggestion btw :smile: I asked you how to serve a SPIFFS static file in a custom handler and you sent me this, it worked so I didn't try it for stability/memory leaks
Me No Dev
@me-no-dev
never my idea not to actually request->send(response) ;)
dragon-engineer
@dragon-engineer
that's not it
Me No Dev
@me-no-dev
what is not it?
dragon-engineer
@dragon-engineer
ah sorry you are right, it's the ending of AsyncWebServerResponse *response = request->beginResponse(SPIFFS, "/404.html");
so what's better way? I asked here and got this solution suggested...
Me No Dev
@me-no-dev
server.onNotFound([](AsyncWebRequest * request){
  AsyncWebServerResponse *response = request->beginResponse(SPIFFS, "/404.html");
  response->setCode(404);
  request->send(response); //<<<very important line of code ;)
}
oops
dragon-engineer
@dragon-engineer
It's there.. I wrote it for the first time and then just omitted it
the problematic handler looks exactly like yours :smile:
Me No Dev
@me-no-dev
then it should not leak… I do not get it...
dragon-engineer
@dragon-engineer
yes, that's why I didn't test it earlier, nothing suspicious around
when I use request->send(404, "text/html", "404 Not Found"); it's all good
Me No Dev
@me-no-dev
what id you just request->send(SPIFFS, "/404.html”);
dragon-engineer
@dragon-engineer
unfortunately I didn't take my ESP module to work again :clap: so I can either send you a zipped solution with html or I'll do it myself in the evening
Me No Dev
@me-no-dev
you do have “/404.html”in the file system right?
dragon-engineer
@dragon-engineer
yes :smile:
Me No Dev
@me-no-dev
please do try tonight
dragon-engineer
@dragon-engineer
it serves the file but leaks
ok I will do the test
Me No Dev
@me-no-dev
how big is that file?
dragon-engineer
@dragon-engineer
like 3kB
Me No Dev
@me-no-dev
hmmm then it’s not the SPIFFS bug we have been having...
dragon-engineer
@dragon-engineer
when serving large files?
Me No Dev
@me-no-dev
yes
dragon-engineer
@dragon-engineer
yes I wouldn't expect/torture the ESP with megabytes of files
Me No Dev
@me-no-dev
30K is enough to trigger it :)
dragon-engineer
@dragon-engineer
oh :smile: a different story then
however, I used to been using gzip compression in my project, and when I just updated SDK to the latest, it's all buggy
*have been, damn
I used this scheme: in SPIFFS just GZipped files, delete normal .css/.js . in the SPIFFS static file handlers was normal .js and path to SPIFFS file .js
this worked like charm until I updated
now it sends garbage (plain gzipped text, without decompressing in the browser)
Me No Dev
@me-no-dev
it still might be connected to the same issue. Does the file editor open fine?
if gzip has errors it would not be recognized and decompressed so it will spit crap
dragon-engineer
@dragon-engineer
I haven't try the editor actually..but will do tonight
Me No Dev
@me-no-dev
editor runs from flash and is gzipped
not SPIFFS ;)
dragon-engineer
@dragon-engineer
I thought the memory might have been corrupted somehow so I even tried another NodeMcu module but with the same result. Then I changed the SPIFFS static handler so that it points to the file .js.gz in the filesystem, then it works a little better, no garbage, but it's a 48kB file and two characters in the javascript are wrong.. instead of quotes there is | character, therefor the script won't work.
I triple checked and reuploaded to the flash but still same, cleaned cache but still sends wrong characters (just the same ones)
Me No Dev
@me-no-dev
@matasondrak fixes for SPIFFS are coming ;) hang tight :)
dragon-engineer
@dragon-engineer
great to hear it because it's actually worse than older releases which worked fine :smile: looking forward to it
Me No Dev
@me-no-dev
it’s a brand new bug :D anjoy :D
dragon-engineer
@dragon-engineer
so (no critically important) update created much worse bugs ? :smile: windows users like me know that very well
Me No Dev
@me-no-dev
:D:D:D:D exactly
dragon-engineer
@dragon-engineer
alright, I'll be available for tests when you release some update, I have both 32Mbit and custom resolderes 64Mbit flash variants
when will we be able to use 64Mbit btw?
Me No Dev
@me-no-dev
@matasondrak PR is esp8266/Arduino#3623
oh.. I got some 16MB wemoses as well to test this :) I vote for extending the day to 36 hours instead of 24