The Scoop and Homebrew manifests have an optional SHA256 field. Instead of re-creating it manually on each build, include creating them in the build scripts.

For example:

• serve_v0.2.0_Windows_x64.sha256

We should have a flag for using a gzip middleware.

Have a look at:

• https://github.com/nytimes/gziphandler
• https://github.com/gin-contrib/gzip/blob/master/gzip.go
• https://github.com/gorilla/handlers/blob/master/compress.go
• https://github.com/go-chi/chi/blob/master/middleware/compress.go

Bug description

serve 0.3.0 fails to start on Mac OS X:

$ serve0.3.0
Killed: 9

Reproduction

curl -ssL https://github.com/philippgille/serve/releases/download/v0.3.0/serve_v0.3.0_macOS_x64 > ~/bin/serve && chmod a+x ~/bin/serve

Info

Example:

• Version: 0.3.0
• Operating system: Mac OS X 10.13.6

In addition to serving a directory on your host computer to colleagues on your local network, it would be awesome if you could also share the directory to people outside of that network, even if you're behind a NAT/firefall.

SSH reverse tunnels make this possible.

Go has an SSH package and it should be possible to open a reverse tunnel within the application itself.

• https://stackoverflow.com/questions/33040563/reverse-ssh-with-golang
• https://gist.github.com/codref/473351a24a3ef90162cf10857fac0ff3

The docsUrl in this line is wrong:

The same applies for the portable nuspec.

This leads to a broken documentation link in the official Chocolatey package gallery.

A Scoop package was added for Windows in #4, now a Snap package should be added for Linux.

• https://docs.snapcraft.io/build-snaps/your-first-snap
• https://docs.snapcraft.io/build-snaps/go

For executing in Linux or a Docker container with Mono installed.

Like this:

#!/bin/bash

# Builds the Chocolatey package if the Windows x64 binary exists.
# Uses Chocolatey via Mono
# Is intended to be used inside a linuturk/mono-choco Docker container

# No "-o pipefail" option for the bash script,
# because when used in the .NET Core SDK Docker container this leads to "invalid option name: pipefail".
set -eux

SCRIPTDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
APPNAME=$(<$SCRIPTDIR/APP_NAME)
VERSION=$(<$SCRIPTDIR/../VERSION)
ARTIFACTSDIR="$SCRIPTDIR/../artifacts"

$SCRIPTDIR/bumpVersion.sh

# Build chocolatey package if a win-x64 SCD was built

if [[ -f $ARTIFACTSDIR/${APPNAME}_v${VERSION}_win-x64/$APPNAME.exe ]]; then
    # Clean and create directories
    rm -f $ARTIFACTSDIR/$APPNAME.*.nupkg
    rm -f $SCRIPTDIR/../chocolatey/tools/serve.exe
    mkdir -p $SCRIPTDIR/../chocolatey/tools
    # Copy SCD files
    cp -r $ARTIFACTSDIR/${APPNAME}_v${VERSION}_win-x64 $SCRIPTDIR/../chocolatey/tools
    # Workaround for a bug where choco uses the wrong working directory when using choco via Mono
    REGEX="<file src=\\\"tools\\\\\**\\\" target=\"tools\" />"
    REPLACEMENT="<file src=\"${SCRIPTDIR}/../chocolatey/tools\\**\" target=\"tools\" />"
    sed -r "s@${REGEX}@${REPLACEMENT}@g" $SCRIPTDIR/../chocolatey/$APPNAME.portable.nuspec > $SCRIPTDIR/../chocolatey/$APPNAME.temp-linux.nuspec
    # Build Chocolatey package
    choco pack "$SCRIPTDIR/../chocolatey/$APPNAME.temp-linux.nuspec" --out $ARTIFACTSDIR
    choco pack "$SCRIPTDIR/../chocolatey/$APPNAME.nuspec" --out $ARTIFACTSDIR
    # Clean up workaround
    rm -f $SCRIPTDIR/../chocolatey/$APPNAME.temp-linux.nuspec
fi

First check if the workaround is still required with the current Chocolatey version.

When executing the Snap, the following error occurs:

$ serve

Serving "." on all network interfaces (0.0.0.0) on HTTP port: 8100

Local network interfaces and their IP addresses so you can pass one to your colleagues:

2018/05/12 12:39:23 route ip+net: netlinkrib: operation not permitted

The same when using -t for testing.

Solution

We probably need to declare some capabilities in the snapcraft.yaml, see:

• https://docs.snapcraft.io/core/interfaces
• https://docs.snapcraft.io/build-snaps/syntax#plugs
• https://docs.snapcraft.io/reference/interfaces (see network-bind)

network-bind is probably necessary for acting as server.

Another interface might be necessary for accessing files in the directory the user requests.

Currently (v.0.2.1) only LAN IP addresses are printed, but in case the user set up port forwarding in his home network or uses serve on a VPS, the external IP address that's reachable from the internet would be useful as well.

Use 3rd party web services to get the external IP address:

• http://ifconfig.co/
• https://httpbin.org/#/Anything/get_anything (origin response)
• others

Make requests to multiple services in case 1) one goes offline in the future and 2) the responses differ (then use the address which most services responded with).

Two things need to be kept in mind:

• Make this optional (maybe true as default, but the user should be able to disable it), because some user's might not want any 3rd party programs to make requests to other services
• When using with -s, the external IP address should be included in the SAN entries

Next to Scoop, Chocolatey is probably the most popular package manager for Windows, so we should have a package for it.

I already created a feed on MyGet: https://www.myget.org/feed/Packages/serve

Maybe later we can add the package to the official Chocolatey feed:

• https://github.com/chocolatey/choco/wiki/CreatePackages
• https://chocolatey.org/docs/create-packages
• https://chocolatey.org/docs/commands-push
• https://chocolatey.org/packages/upload

Create a Scoop package for easier installation on Windows.

• Scoop: http://scoop.sh/
• Wiki: https://github.com/lukesampson/scoop/wiki

The app can first be put into my Scoop bucket and later into the official https://github.com/lukesampson/scoop-extras bucket.

There should be a Docker image for serve.

• This is the easiest way to launch the server, no installation or binary download needed!
• People feel more safe to mount a single directory to a container and know the application in the container can't access anything else in the filesystem.

The version number is currently hard coded in several places:

• serve.go - the actual code
• README
• docs/README
• Scoop manifest
• Hombebrew formula
• Snapcraft configuration file
• VERSION file

Go main packages can be tested as well, so add a serve_test.go and write some tests.

Consider moving the helper functions into their own package, where it makes sense to export them, which in turn makes it more idiomatic to test them (instead of using the main package in serve_test.go).

A Scoop package was added for Windows in #4, now a Homebrew package should be added for macOS.

• https://brew.sh/
• https://github.com/Homebrew/homebrew-core

Tutorials:

• http://octavore.com/posts/2016/02/15/distributing-go-apps-os-x
• https://tech.cars.com/distributing-your-home-grown-tools-to-the-masses-with-homebrew-acb7a62518a8
• https://kev.inburke.com/kevin/install-homebrew-go/

Examples:

• https://github.com/Homebrew/homebrew-core/blob/master/Formula/faas-cli.rb
• https://github.com/jkawamoto/fgo/blob/master/assets/formula.rb (Go template for Homebrew formula)

Even when using serve D:\my\temp, the output says:

Serving "." on all network interfaces (0.0.0.0) on HTTP port: 8100

The "." is wrong in this case.

With v0.2.0 no URL is suggested when using:

• Windows + Wifi
• macOS in general

Add support for those cases.

Instead of relying on network interface names we could check the IPv4 addresses against the default gateway's address.

For example:

• The gateway's address is 123.123.123.0
• Our system, in this example Windows, has (interface name + address):
  • "Ethernet 2": 234.234.234.234
  • "Ethernet 3": 123.123.123.123

If we would choose by name, "Ethernet 2" would match first and we would use that IP address in the URL suggestion, which is the wrong one.

If instead we would match the first three parts of the IP address against the first three parts of the gateway address, we would choose "Ethernet 3", which is the correct one.

This requires determining the gateway's IP address, which is not possible with Go's stdlib. But this package seems to be perfect: https://github.com/jackpal/gateway

Are there any arm images for docker?

• Based on: https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/
• Project: https://github.com/upx/upx
• Doc: http://manpages.ubuntu.com/manpages/bionic/man1/upx-ucl.1.html

Instead of building release artifacts locally, add the following to the .travis.yml: apt-get install -y upx-ucl.

Then either use those artifacts from Travis CI to upload them to GitHub Releases, or use Travis CI to automate the release as well (see hello-netcoreap/.travis.yml for example).

Currently, when a new version of serve is created, a Chocolatey package has to be built and uploaded manually.

This can be automated with https://github.com/majkinetor/au.

Currently serve always binds on 0.0.0.0, but maybe you only want the server to be reachable on a specific address, like localhost for temporary testing without exposing a directory to other network members.

A flag b would make sense for this.

Printint the network interface table probably doesn't make sense in this case, and the URL suggestion could simply be the chosen bind address + port.

A format check and proper message in case of a bad format should be added.

A main network interface on Windows, like "Ethernet 3" can have many addresses and the interesting IPv4 address isn't one of the first two when iterating in Go via net.Interfaces() + iface.Addrs().

So iterate over all addresses as long as either the IPv4 or IPv6 address is empty.

On Linux it looks nice, but also just by accident. On Windows the interface names are longer and the code only fills up to 15 characters, it doesn't cut them off if a string is longer.

Also, the default network interfaces on Windows aren't called eth0 and wlan0, so use the proper Windows interface names for a good suggestion of an IP address that can be shared with colleagues.

Also, in the below example, no IPv4 address is shown for Ethernet 3, although it has one.

   Interface    |  IPv4 Address   | IPv6 Address
----------------|-----------------|----------------
vEthernet (nat) | 172.29.123.123     | foo:bar::::123
vEthernet (Standardswitch) | 172.21.123.123   | foo:bar::::124
vEthernet (DockerNAT) | 10.0.75.1       |
Ethernet 3      |                 | foo:bar::::125
Loopback Pseudo-Interface 1 | 127.0.0.1       | ::1

Hi, thanks for this awesome tool you've built.

have you considered to add a file size information to the served index page? It would help for an end-user to verify that the they download the right file, comparing the file size to the expected value.

It should be possible to protect the access to the shared directory with a password.

If only HTTP Basic Authentication (with username in addition to a password) is possible, then that's ok as well. But password-only is preferable.

• https://github.com/abbot/go-http-auth
• https://stackoverflow.com/questions/25552107/golang-how-to-serve-static-files-with-basic-authentication
• https://gist.github.com/elithrar/9146306

Tor hidden services (v3) have the advantage of being accessible from the internet without having to set up any port forwarding from the router (that's using NAT). Additionally the traffic is encrypted by default.

It should be possible to launch a temporary hidden service with a single simple serve command.

Libraries:

• For the Tor service itself: https://github.com/ipsn/go-libtor
  • Mentions it can be used with bine
  • Maybe as an alternative: https://github.com/cretz/tor-static
• For creating a hidden service: https://github.com/cretz/bine
  • Mentions it can be used with tor-static

With those libraries it should be possible to include Tor in the single serve binary, without requiring the user to install anything.

Other info:

• Also check out https://github.com/lightningnetwork/lnd, which includes the option to create a Tor hidden service and it's a single binary as well
• Read https://2019.www.torproject.org/docs/tor-onion-service.html.en
• Regarding HTTPS: https://blog.torproject.org/facebook-hidden-services-and-https-certs
• https://stem.torproject.org/tutorials/over_the_river.html
  • Mentions https://tor2web.org/ to test if a hidden service works without having to use Tor on the client side
• For setting up client authorization: https://2019.www.torproject.org/docs/tor-manual-dev.html.en#_client_authorization
  • But maybe our current HTTP Basic Authorization is enough?
• Also check out https://github.com/micahflee/onionshare

Instead of just HTTP, HTTPS should be possible as well.

• https://github.com/denji/golang-tls
• https://golang.org/src/crypto/tls/generate_cert.go
• https://github.com/kabukky/httpscerts