Simple Web Server
What it is
sws is a self-contained web server that serves files which runs on Linux, Windows and (untested) Mac OS X. Once built,
the executable should have no dependencies, e.g., it does not require OpenSSL. Convenience and security are the
main goals. It has no config files, and only a few, if any, easily provided command line parameters should be necessary.
If convenience and security conflict, I’m willing to sacrifice a little convenience for security, but only a little.
Often such conflicts are largely resolvable. For example, requiring a password and using TLS improve security, but
making a password or a certificate are inconvenient, so
sws can generate these. Currently, support for generating
a certificate is removed.
Use-case 1: Large file transfer
You want to send a large file to someone. You browse to the directory containing it, type “
sws”, and give them
your public IP. They browse to it and download. Maybe they are the ones sending the file, but aren’t “technical”.
You browse to an empty directory, type “
sws -w” or “
sws -U”, and give them your public IP. They browse to it and upload.
In reality, you need to figure out what your public IP is and open a port in your firewall.
sws will currently
use Google’s STUN server to attempt to figure out your public IP.
Use-case 2: Client-side code demo/development
You build an unhosted web application or you mock out AJAX responses. You can do some
simple testing by running “
sws -d”. (Admittedly, using a file URI will probably work pretty well too, though maybe
not so much for mocked POST requests…) You want to show a friend. Just make that “
Use-case 3: Instant read-only Git hosting
git clone --bare /path/to/myrepo ~/public/myrepo.git cd ~/public/myrepo.git mv hooks/post-update.sample hooks/post-update chmod a+x hooks/post-update git update-server-info sws --no-compress -H example.com ~/public/
git -c http.sslVerify=false clone https://example.com:3000/myrepo.git
This would be even more instant with darcs.
What it isn’t
This is not an app server. It reads and writes files, and that’s all it will ever do. There is no way to add code to it. The Haskell ecosystem has plenty of good web frameworks. This is not one of them. It’s an application, not a framework. (Well… you could do something with named pipes and/or interesting file systems… but you really shouldn’t.)
All notable changes to this project will be documented in this file.
0.4.3.0 - 2018-09-15
- Upper bound bumps.
- Using -X to add headers will remove headers added by default. Before it would lead to duplicate headers.
0.4.2.0 - 2018-06-01
- Store uploaded files directly in target directory rather than first uploading to a temp directory then copying.
0.4.1.0 - 2018-02-14
- Upload only mode.
- Options to control STUN.
- Options to control what happens when a file is uploaded which already exists.
0.4.0.0 - 2017-09-10
- Upper bound bumps.
- TLS certificate generation. The functionality was removed from the crypto library this depends upon.
0.3.1.2 - 2015-08-25
- Upper bound bumps.
- Make STUN server look up a bit more robust.
0.3.1.1 - 2015-04-17
- Upper bound bump to support GHC 7.10.
0.3.1.0 - 2015-01-07
- Added Public mode.
- Dependency bounds changed on warp-tls to pull in critical bug fix.
0.3.0.0 - 2014-12-29
- CHANGELOG.md and README.md
- Support for generating throw-away TLS certificates.
- Support for generating password for Basic Authentication.
- Support for adding custom headers to all responses.
- Support getting public IP via Google STUN server.
- Added Quiet mode and Dev Mode.
- Change defaults to use HTTPS and Basic Authentication.
- Change display of connection information to a copyable address.
- Currently works around a bug in x509 to generate valid certificates. (Pull request outstanding.)
- --allow-http is removed. It did not appear to work anyway.
0.2.0.0 - 2014-12-06
- Support for uploading files. This includes overwriting existing files.
0.1.0.0 - 2014-11-11
- This is intended to be fully usable for it’s intended purpose, namely statically serving a directory tree.