GitLab

I'm not entirely clear on the role that this package is filling, but
this description seems like a reasonable guess based on a quick skim
through it's exported API.

Once the server is asked to shut down, we stop accepting new
connections, but the 'manners' graceful shutdown will wait for
all existing connections closed to close before finishing.

For keep-alive connections this will never happen unless the
client detects that the server is shutting down through the
ipfs API itself, and closes the connection in response.

This is a problem e.g. with the webui's connections visualization,
which polls the swarm/peers endpoint once a second, and never
detects that the API server was shut down.

We can mitigate this by telling the server to disable keep-alive,
which will add a 'Connection: close' header to the next HTTP
response on the connection. A well behaving client should then
treat that correspondingly by closing the connection.

Unfortunately this doesn't happen immediately in all cases,
presumably depending on the keep-alive timeout of the browser
that set up the connection, but it's at least a step in the
right direction.

When closing a node, the node itself only takes care of tearing down
its own children. As corehttp sets up a server based on a node, it
needs to also ensure that the server is accounted for when determining
if the node has been fully closed.

The server may stay alive for quite a while due to waiting on
open connections to close before shutting down. We should
find ways to terminate these connections in a more controlled
manner, but in the meantime it's helpful to be able to see
why a shutdown of the ipfs daemon is taking so long.

- Modified Godeps/Godeps.json by hand
- [TEST] Updated welcome docs hash to sharness
- [TEST] Updated contact doc
- [TEST] disabled breaking test (t0080-repo refs local)

License: MIT
Signed-off-by: Kevin Wallace <kevin@pentabarf.net>

Each option now additionally returns the mux to be used by future options. If
every options returns the mux it was passed, the current behavior is unchanged.

However, if the option returns an a new mux, it can mediate requests to handlers
provided by future options:

    return func(n *core.IpfsNode, mux *http.ServeMux) (*http.ServeMux, error) {
      childMux := http.NewServeMux()
      mux.Handle("/", handlerThatDelegatesToChildMux)
      return childMux, nil
    }

License: MIT
Signed-off-by: Kevin Wallace <kevin@pentabarf.net>

- core: daemon stdout print to cmd + daemon init checks
- core: fixed bug where the gateway was printed as "API"
- sharness/test-lib: daemon init checks
- sharness/test-lib: portable TCP port check
- sharness/init: fix test bits output
- sharness: use common hashes in one place.
- move t0100-http-gateway -> t0111-gateway-writable
- sharness: test-lib funcs for gateway config
- sharness/t0111-gateway-writable: use sh funcs
- sharness/t0111-gateway-writable: fixes
  - escape all vars (always `cmd "$VAR"` never `cmd $VAR`)
  - use $FILEPATH, not $path
  - last test seems to fail

PACKAGE DOCUMENTATION

package corehttp

    FUNCTIONS

    func GatewayOption(n *core.IpfsNode, mux *http.ServeMux) error

    func ListenAndServe(n *core.IpfsNode, addr ma.Multiaddr, options
    ...ServeOption) error

    func WebUIOption(n *core.IpfsNode, mux *http.ServeMux) error

    TYPES

    type ServeOption func(*core.IpfsNode, *http.ServeMux) error

    func DaemonOption(cctx commands.Context) ServeOption