Skip to content

liberda/HTTP.sh

Repository files navigation

HTTP.sh

Node.js, but | sed 's/Node/HTTP/;s/js/sh/'.

HTTP.sh is (by far) the most extensible attempt at creating a web framework in Bash, and (AFAIK) the only one that's actively maintained. Although I strive for code quality, this is still rather experimental and may contain bugs.

Originally made for Junction Stupidhack 2020; Created by sdomi, ptrcnull and selfisekai.

Quick Start

If you want to build a new webapp from scratch:

./http.sh init
./http.sh

If you're setting up HTTP.sh for an existing application:

git clone https://git.sakamoto.pl/laudom/ocw/ app # example repo :P
./http.sh

We also support Docker! Both a Dockerfile and an example docker-compose.yml are included for your convenience. Containerizing your webapp is as easy as docker-compose up -d

Dependencies

  • Bash (4.x should work, but we'll need 5.0 soon)
  • Ncat, not openbsd-nc, not netcat, not nc
  • socat (because the above is slightly broken)
  • pkill
  • mktemp
  • jq (probably not needed just yet, but it will be in 1.0)
  • dd (for accounts, multipart/form-data and websockets)
  • sha1sum, sha256sum, base64 (for accounts and simple auth)
  • curl (for some demos)

Known faults

  • can't change the HTTP status code from Shell Server scripts. This could theoretically be done with custom vhost configs and some if statements, but this would be a rather nasty solution to that problem.
  • $post_multipart doesn't keep original names - could be fixed by parsing individual headers from the multipart request instead of skipping them all
  • it won't ever throw a 500, thus it fails silently

Directory structure

  • ${cfg[namespace]} (app by default)
    • ${cfg[root]} (webroot by default) - public application root
    • workers/ - scripts that execute periodically live there (see examples)
    • views/ - for use with HTTP.sh router
    • config.sh - application-level config file
  • config
    • master.sh - main server config file - loaded on boot and with every request
    • host:port - if a file matching the Host header is found, HTTP.sh will load it request-wide
  • src
    • server source files and modules
    • response
      • files corresponding to specific HTTP status codes
      • listing.sh (code 210) is actually HTTP 200, but triggered in a directory with autoindex turned on and without a valid index.shs file
  • templates - section templates go here
  • secret - users, passwords and other Seecret data should be stored here
  • storage - random data storage for your webapp

Variables that we think are cool!

  • get_data - holds data from GET parameters
    • /?test=asdf -> ${get_data[test]} == "asdf"
  • params - holds parsed data from URL router
    • /profile/test (assuming profile/:name) -> ${params[name]} == "test"
  • post_data - same as above, but for urlencoded POST params
    • test=asdf -> ${post_data[test]} == "asdf"
  • post_multipart - contains paths to uploaded files from multipart/form-data POST requests. WARNING: it doesn't hold field names yet, it relies on upload order for identification
    • first file (in upload order) -> cat ${post_multipart[0]}
    • second file -> cat ${post_multipart[1]}
  • r - misc request data
    • authorization
    • content_boundary
    • content_boundary
    • content_length
    • content_type
    • headers
    • host
    • host_portless
    • ip
    • post
    • proto
    • status
    • uri
    • url
    • user_agent
    • view
    • websocket_key
  • cfg - server and app config - see config/master.sh for more details

Fun stuff

  • To prevent running malicious scripts, by default only scripts with extension .shs can be run by the server, but this can be changed in the config.
  • ${cfg[index]} ignores the above - see config/master.sh
  • Trans rights!
  • SHS stands for Shell Server.