Panic accessing /logs via websocket

[smlx]

First, thanks for the great software :-)

I'm seeing a panic when accessing /logs via a websocket. Here's the stack trace:

# logspout v3.2.5 by gliderlabs
# adapters: raw syslog multiline tcp udp tls
# options : persist:/mnt/routes
# jobs    : pump routes http[routes,logs]:80
# routes  : none
panic: send on closed channel

goroutine 41 [running]:
github.com/gliderlabs/logspout/router.(*containerPump).send(0xc42022f560, 0xc420053280)
	/go/src/github.com/gliderlabs/logspout/router/pump.go:384 +0x129
github.com/gliderlabs/logspout/router.newContainerPump.func1(0x5634dbc5087f, 0x6, 0x5634dc174ac0, 0xc42023c060)
	/go/src/github.com/gliderlabs/logspout/router/pump.go:364 +0xbc
created by github.com/gliderlabs/logspout/router.newContainerPump
	/go/src/github.com/gliderlabs/logspout/router/pump.go:373 +0x174

You can reproduce this by running logspout via docker:

docker run -d --name="logspout" --volume=/var/run/docker.sock:/var/run/docker.sock --publish=8000:80 --restart=always gliderlabs/logspout

and then hitting the endpoint with curl:

$ curl -H "Connection: Upgrade" -H "Upgrade: websocket" http://127.0.0.1:8000/logs
mismatch challenge/response

mismatch challenge/response is the only output.

[vtereso]

I also experienced this when attempting to use gorilla/websocket to connect to the endpoint, but when I used the golang.org/x/net/websocket instead, it worked as intended. Not sure what other libraries will have conflicts as well.

[semk]

logspout is expecting a browser client to access the websocket endpoint. Due to missing origin header the panic was occuring. I've added a patch which allows non-browser clients to access this endpoint. #502