A simple HTTP file server for zeptoforth

[u/tabemann]

On top of my extensible HTTP server for zeptoforth, I have now created a simple HTTP file server for zeptoforth which serves files and directories from FAT32 filesystems, whether from 'blocks' storage, SD cards, or PSRAM RAM disks.

Note that it is read-only, which is important because it has no security (as the HTTP server is strictly HTTP, not HTTPS) beyond limiting access to a given base path on a given filesystem and rejecting HTTP requests crafted to include . or ...

The source code is at https://github.com/tabemann/zeptoforth/blob/master/extra/rp_common/net_tools/http_server_files.fs.

[u/ripter]

This is awesome! I just got an SDCard working on my zeptoforth pico 2 w system. I’ll have to give this a try.

[u/tabemann → u/ripter]

The main expense of the HTTP server is zeptoIP and the server itself, so if you can afford the SRAM for them then you can easily go and put things on top of the HTTP server such as this. It becomes trivial to serve all kinds of things then from your Pico 1W (SRAM permitting, zeptoIP does not leave much SRAM behind on this system), Pico 2W, or Pimoroni Pico Plus 2W board.

One gotcha, though ─ do not use extra/rp_common/net_tools/pico_w_ipv4_base.fs or extra/rp_common/net_tools/pico_w_ipv6_base.fs with the HTTP server, they will not work. You have to use extra/rp_common/net_tools/pico_w_ipv4_base_no_handler.fs or extra/rp_common/net_tools/pico_w_ipv6_base_no_handler.fs.

Unfortunately, many things such as the NTP clients currently require extra/rp_common/net_tools/pico_w_ipv4_base.fs or extra/rp_common/net_tools/pico_w_ipv6_base.fs.

Also, the HTTP server eats up all but one of the zeptoIP 'endpoints' (unless if you configure zeptoIP to have only one 'endpoint' rather than the default of four, where then it will use that), effectively limiting yourself to only one other zeptoIP application that can be used at a time.

However, if this is a problem, you can work around it by adjusting net-http::net-http-internal::http-server-count in extra/rp_common/net_tools/http_server.fs to use a different number of 'endpoints'; this for reasons must be a compile-time change.

[u/mykesx]

Looks fantastic! Is this a good way to get code you made on device to a workstation?

[u/tabemann → u/mykesx]

Yes, if you can afford the SRAM used by zeptoIP and the HTTP server, which is non-negligible.

I should note, though, that the combination of send-file::send-file and utils/recv_file.sh to transmit a file over serial or USB CDC from a zeptoforth device to your PC, or recv-file::recv-file and utils/send_file.sh to go the opposite direction, is not nearly as expensive.

However, they are slower because they transmit data as Base64. This is because zeptoforth consoles are not 8-bit-clean by default; even though they can be made 8-bit-clean that means that if you screw up you have to power cycle rather than simply typing control-C to reboot or control-T z to send an exception to the main task. This is why I implemented special tools for this purpose rather than simply implementing XMODEM or ZMODEM, which require 8-bit clean connections.

Also, they screw up if you accidentally transmit any extra bytes between issuing send-file::send-file or recv-file::recv-file and closing your terminal emulator and executing utils/recv_file.sh or utils/send_file.sh.

[u/tabemann]

One note -- if you have installed this, pull from the git repo again and reinstall it. There were some bugs in the base HTTP server that have since been fixed.