10 comments

[ 3.2 ms ] story [ 37.0 ms ] thread
pipe incoming request bodies into commands as `stdin`

very cool. could be pretty useful :)

This kind of reminds me of the venerable tool "netcat." Through such simplicity, elegance and power emerge.

If you've used netcat before you know how useful it can be, but also be very careful ever exposing it to the internet (or even your LAN if there could be malicious users connected).

How would this compare to websocketd ?
It's very similar to websocketd, however this is intended to be used by one-shot scripts over HTTP.

websocketd uses the WebSocket protocol for streaming scripts, whereas script-httpd uses plain HTTP for terminating scripts.

Great.

Can we use pipes of commands for processing?

Is it possible to avoid creating processes along the way - to have a sort of precompiled service in memory, waiting for requests?

It's possible to use pipes, as well as redirection, but you need to do something like:

script-httpd bash -c 'some_command | some_other_command 2>&1'

For having a longer running service in the background it might make more sense to just use something like nginx as a reverse proxy. It is something I've been pondering though.

Hmm looks similar to stdinho https://github.com/ostrolucky/stdinho. Difference is that script-httpd accepts incoming http data and pipes it to process, returning result. Stdinho does not accept incoming http data, it just takes whatever stdout process returns right as process starts. This allows it to not wait for http connection and start buffering before that.
stdinho just reads raw data from stdin, whereas script-httpd proxies to an executable command.
That's what I said, right?
Huh, seems like a more convenient CGI