Use upstream facil.io

[sea-grass]

This PR updates the project to reference the facil.io source as an upstream dependency, rather than an in-source copy.

I noticed in #140 that you're gearing up for a facil.io update and thought that this might make the transition easier, since you no longer have to worry about keeping the source tree in sync with that of facil.io. This method of depending on/building upstream C sources was inspired by the projects in the All Your Codebase org (see e.g. the zstd build.zig).

---

I originally based this branch off master, then noticed that I would have to do some repeated refactorings already present in your zig-master branch (as I'm using Zig 0.14.0-dev.1911+3bf89f55c currently), so I merged it into this branch. This PR still points at master, but feel free to change the base as you see fit.

---

Summary of changes:

• The Zap build.zig now references a local module as a dependency at the path ./facil.io (where the in-source copy had previously lived)
• The facil.io sources at ./facil.io have been deleted, except for build.zig, build.zig.zon, and src/facil_zig.c (flake.lock and flake.nix are untouched, but I'm not using Nix currently so I didn't feel like I could evaluate whether those should stick around or not)
• The facil.io module now references the sources using a build dependency, using the current commit at the facil.io 0.7.x tag
• The facil.io module creates the facil.io library as an artifact
• The Zap build.zig links the facil.io module's artifact
• And a minor tweak: Use b.allocator instead of std.heap.page_allocator in the facil.io module's build.zig

[renerocksai]

Hi & thanks for your work.
e75e1b0 intentionally merged zap & facil.io.
As mentioned in the README, zap should always work with the latest stable release of zig. Hence the zig-master branch to also support zig master. So this PR should be based off of zig-master orelse building with stable zig will fail.
I can clean this up but need to think about whether I really want to have facil back as external dependency. It might make sense if frequent changes are to expect in a future version of facil.io which we also want to quickly integrate into zap.

[sea-grass]

Hi, thank you for making this library.

I hadn't seen that commit, so thanks for sharing that. I'm curious: what are the benefits of folding the facil.io source into this repo over referencing it as a dependency? I hadn't looked too deeply into the differences between the two source trees, so I'm not sure how much patching had been done between the facil.io repo and this one, other than the addition of the fio_zig.c Zig compatibility layer. I could see the benefit if there are extensive patches to source files. One thing that I want to note is that it's not clear to me as a user which version of facil.io zap bases its copy off of, or where exactly it diverges - if not included as a dependency, maybe it could be included as a fork/submodule? This is all totally your call though. In any case, I rebased this branch and pointed my PR at zig-master.

Why I became interested in facil.io as a dependency was because I was looking for a way to set default headers for particular mime types when serving files through the public folder. I was looking into implementing this feature in facil.io when I saw that Zap wasn't depending on the source repo directly. My use case is that I use Zap to start a simple static server as part of local development, like $ serve path/to/public. Zap (or I should say facil.io) always sets the Cache-Control header to max-age, which means that as I rebuild the contents of my public folder, my browser keeps the cached version. To get around this today, I keep my developer tools open with the "disable cache" option checked, but my preferred solution would be to configure the behaviour for the text/html mime type to set the default cache control header value to no-cache.

[renerocksai]

Hi,

Pre-zig-package manager I used to have facil.io as git submodule and had a zig.build that would apply my patches to facil.io.

After that, I maintained a fork of it. You can see it in the .zon file of above's commit. I won't go into details as you can check out the fork & commit history. Note that some were bugfixes like for cookies and sendFile64.

Eventually, co-versioning, co-tagging, co-releasing etc. became too much of a burden (especially when just making tiny, quick changes) to me given that I never have enough time, so I decided to just swallow facil.io; it's not like it's been changing much.

Now, to your problem: as far as I recall, facil.io does not set your headers to max-age (I could be wrong though wrt sendfile2), but rather sets caching headers to 1 hour.

So, you could fork zap and change the max age from 1 hour to sth different 😄 - or, what I would recommend: write a tiny request handler that just takes the request's path, adds a prefix to it, and calls zap.request.sendfile on it, with your custom cache-control headers.

My public_folder philosophy is: as with all of zap: use what's there to get you started. If you want different behavior (due to the nature of facil.io's public folder implementation:), just provide your own handler. It's probably very few lines of code.

[renerocksai]

BTW: Likely, when facil.io 0.8 comes out (and is probably more active), it will make much more sense to depend on it via the build system.

[boazsegev]

FYI: in facil.io 0.8.x, the max-age is dynamically settable in the HTTP settings and defaults to zero (0)... no caching.

This is one of the breaking changes in the new version.