Solutions for scripting?

[Physics-Dude]

I was pleased to see static-web-server recently get added to the Truecharts app catalog for TrueNAS Scale. It works great and setup was trivial! However it was novice of me to assume it would parse simple php scripts.

Reading further, I cant seem to find something akin to the simplicity of static-web-server that also incorporates php or another common scripting language. My particular application is simple enough; a static webpage with a simple php script in the back end that acts as a kind of sanitizing relay service to a Discord API. It doesn't even output anything to the browser.

Would that kind of functionality ever make it to static-web-server? Or are there other solutions available for users like me?

[joseluisq]

Glad to hear SWS is supported on TrueNAS Scale via Truecharts. I use TrueNAS Scale at home so I will give it definitely a try.

About the scripting solution topic.
Unfortunately, SWS was not designed with that in mind, therefore scripting functionality is not supported. Basically, you will not find a related topic in the docs at least.
However, I can tell you that I also thought roughly about the same idea some time ago when I was doing perf tests for SWS with wrk and lua scripts.
So I thought maybe it could be useful for some sort of things if we support that as well in SWS, let's say: FastCGI.
Anyway, although I'm not averse to the idea. I do not have any clue at the moment. So I will encourage people interested in the feature to suggest something or even come up with some proposal to have a ground for discussion.

Regarding your use case.
I do not know a server with the simplicity of SWS has such functionality. But probably Caddy's php_fastcgi could be an option for you if you don't want to deal with Nginx or Apache FastCGI setups.

[joseluisq]

Here are some updates after a quick exploration/reasoning of the topic from my side.

I see three ways that one can use in general if we want someday to introduce scripting functionality as a feature in SWS.

1. Embedding: Lua looks like a good candidate and is more convenient in regards to binary size, performance, and resources wise than embedding PHP for example. But it will mean that one has to ship the runtime as part of the binary as well and take care of the details of such tight integration. I see the embedding option here, in my humble opinion as more suitable for taking further advantage of the program that will embed it than just running a script. For example be able to control/customize headers, responses, etc. But I do not see a reason (right now) because SWS already supports that at its level of course.
2. FastCGI: Since it is a standardized way to interface with external programs, it could be used to support various languages but it requires obviously to have another process to communicate. Since SWS is a web server intended to serve static content only. I don't see a reason to interface with other languages unless SWS is a proxy server, which is not the case and it will never be.
3. Child Processes: If we just want to run one or more scripts in parallel and in an isolated environment then it can be an option. It is more secure and lets dependencies like interpreters up to users. This also does not require any external dependency than Rust std::process in comparison to the other two.

Again, this is just an exploration to incentivize discussion. So I will continue exploring the topic in detail.
But if you have any ideas just let me know.

[Physics-Dude]

I appreciate the insight. I've been meaning to test out Caddy once I have the time between work/other projects. It'll take me some time to learn how to set it up as a custom-app with Truecharts. It looks like it would serve the purpose I need though at first glance.

I've only been using TrueNAS for a few weeks, but ultimately I'm just trying to retire these Raspberry PI computers with a LAMP stack (hold the mysql) that have been hosting aforementioned static web pages with minimal back-end php for nearly 10 years. SWS on Treucharts has been useful for some of those static pages I must say however due to its convenience and ease of use.

[joseluisq]

FYI there is some exploratory stuff going on #254 related to the topic that I'm evaluating, so let's see how it goes.

[funkyfuture]

i have sympathy for the exploration of Lua-integration, for the sake of Lua. but so far my motivation to use the SWS is that it has so few features and thus a small attack surface. to directly address the original posting: a PHP interpreter is the last i want within my system landscape.

i find the addition of dynamic content generation to a product whose adjunct is static counterintuitive and debatable. if such features would be added, i'd appreciate if these were optional build features and that different builds would be published.

and now that i'm discussing this aspect: imo even transport encryption isn't necessarily part of a static web server. suitable reverse proxies are available to serve this purpose and allow the segregation of concerns.

[joseluisq]

i have sympathy for the exploration of Lua-integration, for the sake of Lua. but so far my motivation to use the SWS is that it has so few features and thus a small attack surface. to directly address the original posting: a PHP interpreter is the last i want within my system landscape.

Fair point here. The exploration phase of this was just to see a bit closer to what this proposal could mean for SWS.
What I can say is that although a scripting feature could be useful for certain things, it would be incompatible with the aims of SWS as a project. SWS is focused on being as small as possible webserver with a focus on security (e.g. Rust) and performance. So I agree, adding dynamic scripting support should open the security surface even more rather than narrow it.

i find the addition of dynamic content generation to a product whose adjunct is static counterintuitive and debatable. if such features would be added, i'd appreciate if these were optional build features and that different builds would be published.

Yes, features like this should be optional and not a part of the resulting binary.
For that matter, some ideas come to mind. For example, making SWS pluggable via loading dynamic libraries or WASM plugins. This is a whole topic to explore too (pros & cons) and not even in the roadmap but it could allow users to build their stuff (e.g. Lua scripts).

and now that i'm discussing this aspect: imo even transport encryption isn't necessarily part of a static web server. suitable reverse proxies are available to serve this purpose and allow the segregation of concerns.

I was also thinking about this. TLS can perfectly be decoupled from SWS (alluding to my previous point about having a pluggable SWS). But what SWS project could do about this too is narrow even more the stack surface by coming with minimal batteries included (e.g. without TLS, http2, etc). In that regard, there are ideas to build a more pragmatic SWS binary without that and having the minimum required feature set to serve a website, something like having a minimal SWS binary version, it needs exploration too. However, the option right now that users have is to build SWS themself by turning off Cargo features (e.g. TLS) that with Rust/Cargo is fairly "easy" to do https://static-web-server.net/building-from-source/.

[joseluisq]

Closing the thread as the PoC is closed too. See #254 (comment).

Thanks @funkyfuture for pointing your concerns out.

If you have ideas or want to discuss please feel free to do it or join our Discord server.

[yonas]

For example, making SWS pluggable via loading dynamic libraries or WASM plugins.

Adding a plugin framework would be nice.