Skip to content

vernisaz/simhttp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

320 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SimHttp - Rust web server (aka TRWS)

Purpose

It is a web server for personal Rust/Swift/PHP web applications. It supports servicing files and executing CGI scripts.

History

I've implemented TJWS back in 1999. It has a purpose to run and debug Java web applications. However the interest to Java dropped recent years, so I decided to implement a similar purpose server in Rust.

TRWS - is a successor of TJWS, but instead of servlets it runs CGI web applications that can be written in any language including Rust. It also supports websocket endpoints. They are applications supporting an OS piping mechanism. Such approach is more beneficial than offered by other Rust web servers, because doesn't require to rebuild the entire server at every serviced app change.

Obviously SimHttp is CI/CD friendly.

A CGI Rust app can run as in CLI mode as in a web mode without any change.

The server is perfectly suitable for an embedded development. You can deploy it on an embedded platform. CGI endpoints can be developed in C, Swift, Rust, PHP and so on.

Building

A RustBee script file is provided to build the server. There are 4 dependencies from the micro libraries (crate) pool. The repositories should be cloned and corresponding crates built first.

The directory where all rlib resides has to be specified in crate_dir variable of bee.7b script. It has to exist before building crates and the server.

The following directories structure is expected to build the server

├─projects┐
│   ┌─────┘
│   ....
│   ├─simscript
│   ├─crates
│   ├─simhttp
│   ├─right_slash
│   ├─simjson
│   ├─simtpool
│   ├─simweb
│   ├─simcli
│   ├─simtime
│   .....
....

The server is built by executing rb in its repository.

Note that starting from version 1.31, Simple HTTP can support gzip content encodig. It can be used with chunked transfer encoding. You need to checkout 3rd party repositories, and build the compressor crate as described here. And then set gzip variable of bee.7b to true, when build the server.

Configuring

One JSON file is used for configuring the server. The file has to be in the current working directory the server ran from. An example of env.conf file is a self describing. Specify a current working directory in .service script, when you launch the server as a service. The same executable of the server can be used for multiple configurations. Obviously the listening port or/and the binding address have to be different in the configurations.

JSON attribute Type Purpose Default
bind string bind address, 0.0.0.0 for any none
port number listen port none
threads number number threads in the server thread pool none
no terminal bool do not use any terminal out false
keep_alive_secs number keep a connection alive in seconds, 0 - one time use 10
max_requests_per_connection number max requests in a keep alive connection, 0 - no limit 0
ping_interval_mins number ping in minutes of a websocket connection, 0 - no ping 30
max_chunk_size_kilo number max chunk size in kilobytes (0 no chunks, the complete load in memory) 0
max_response_size_kilo number max response size in kilobytes (0 no limit) 0
max_request_size_kilo number max request size in kilobytes (0 no limit) 0

Support of secure connections

Currently the server doesn't support direct SSL/TLS connections. Use any reverse proxies like Nginx, Caddy, or Traefik for that. It gives also benefits to run the server from a regular user account.

The limitation of not supporting SSL/TLS can be reconsidered in the future.

Running

Just launch simhttp. If no terminal set to `true', then press 'q' for stop. (See a note in the issues.) Use 'kill' to stop the server in all other cases.

If you run simhttp in a SSH session and want to keep it running after the session gets closed, then use - "no terminal": true property in the configuration file and launch it with ending &. The server will be less verbose in the case.

./simhttp & disown

Use disown to keep the server running after SSH session was disconnected. If you still want to see an occasional server output to a console, set "no terminal": false, and then run it using nohup utility as:

nohup simhttp &

or as an alternative, run

screen

and then,

  • Run simhttp: within the screen session.
  • Detach the screen session: Press Ctrl-A then Ctrl-D.
  • Log out: of the SSH session.
  • Reattach the screen session: later:

screen -r

tmux can be also used similarly to the screen.

Finally, you can run simhttp in a separate session using:

setsid ./simhttp

and its output will be discarded unless you redirect it to some file or null, like > /dev/null 2>&1.

bee.7b contains details how to run it in the background under Windows. A script with launching simhttp in background will be generated by running rb package.

Service

You can also run the server as a service on Windows, Linux, BSD, and Mac.

How it can be done on Linux, it's described in the document.

Regarding Windows, use a service wrapper, or update my service C code from there to Rust.

Mac service should look similar to FreeBSD and I will document that after purchasing Neo.

Websocket

The server provides a limited support of WebSocket protocol as WS-CGI. Only UTF-8 string packets are supported.

Popular CGI scripts

How to use such CGI scripts, as php_cgi, is described there.

How to set a default time zone for PHP? Locate php.ini first. Prepare a simple .php file for that as

<?php 
phpinfo(); 
?>

and safe it under phpinfo.php. Run the file using a browser and then use the php.ini location edit it:

sudo nano php_ini_location

Search for date.timezone (Ctrl+W), uncomment the line and set the desired timezone. Save .ini file.

How to compare it to miniserve and other Rust webservers

If you didn't check miniserve yet, then do it now. More likely you will be satisfied with it. Major difference of the TRWS is that it can be extended by CGI scripts and CGI websocket endpoints. For example, I implemented TOTP with web interface, I couldn't do without SimHTTP. SimHTTP is decoupled from deployed Rust applications, and you can deploy them without any change of the server and even dynamically.

Status

Current version is SimHTTP/1.31b84. It's a beta version.

About

A simple web server in Rust

Resources

Stars

Watchers

Forks

Packages

 
 
 

Contributors