pieterlouw / caddy-grpc Goto Github PK

maybe the same as improbable-eng/grpc-web#57 ?
i.e.:
browser - caddy(gprc-web proxy) - server
In our test, browser closed, server still sends data to caddy.
If caddy detected the browser's disconnection, and close the connection to server, then we could detect. However, it seems caddy still hold the connection to server.

$ wget "https://caddyserver.com/download/darwin/amd64?license=personal"
--2018-03-30 08:38:42-- https://caddyserver.com/download/darwin/amd64?license=personal
Resolving caddyserver.com (caddyserver.com)... 138.68.240.78
Connecting to caddyserver.com (caddyserver.com)|138.68.240.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
...

$ wget "https://caddyserver.com/download/darwin/amd64?plugins=http.grpc&license=personal"
--2018-03-30 08:39:14-- https://caddyserver.com/download/darwin/amd64?plugins=http.grpc&license=personal
Resolving caddyserver.com (caddyserver.com)... 138.68.240.78
Connecting to caddyserver.com (caddyserver.com)|138.68.240.78|:443... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2018-03-30 08:39:42 ERROR 500: Internal Server Error.

Caddy 0.10.4 fails to start because there are multiple registrations for /debug/requests. A build without this plugin runs fine.

Steps to reproduce the issue:

$ curl -Lsf 'https://caddyserver.com/download/linux/amd64?plugins=dns,http.authz,http.awslambda,http.cgi,http.cors,http.datadog,http.expires,http.filemanager,http.filter,http.git,http.gopkg,http.grpc,http.hugo,http.ipfilter,http.jwt,http.login,http.mailout,http.minify,http.prometheus,http.proxyprotocol,http.ratelimit,http.realip,http.reauth,http.upload,net,tls.dns.cloudflare,tls.dns.digitalocean,tls.dns.dnsimple,tls.dns.dnspod,tls.dns.dyn,tls.dns.exoscale,tls.dns.gandi,tls.dns.googlecloud,tls.dns.linode,tls.dns.namecheap,tls.dns.ovh,tls.dns.rackspace,tls.dns.rfc2136,tls.dns.route53,tls.dns.vultr' | tar -xvz caddy && ./caddy
panic: http: multiple registrations for /debug/requests

goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x1e5fc60, 0x14938e2, 0xf, 0x1be32e0, 0x14e6c40)
	/usr/local/go/src/net/http/server.go:2254 +0x610
net/http.(*ServeMux).HandleFunc(0x1e5fc60, 0x14938e2, 0xf, 0x14e6c40)
	/usr/local/go/src/net/http/server.go:2286 +0x55
net/http.HandleFunc(0x14938e2, 0xf, 0x14e6c40)
	/usr/local/go/src/net/http/server.go:2298 +0x4b
golang.org/x/net/trace.init.1()
	/gopath/src/golang.org/x/net/trace/trace.go:115 +0x42
golang.org/x/net/trace.init()
	/gopath/src/golang.org/x/net/trace/trace_go17.go:22 +0x1cd
google.golang.org/grpc.init()
	/gopath/src/google.golang.org/grpc/trace.go:105 +0x82
github.com/improbable-eng/grpc-web/go/grpcweb.init()
	/gopath/src/github.com/improbable-eng/grpc-web/go/grpcweb/wrapper.go:115 +0x62
github.com/pieterlouw/caddy-grpc.init()
	src/github.com/pieterlouw/caddy-grpc/setup.go:90 +0x52
github.com/mholt/caddy/caddy/caddymain.init()
	src/github.com/mholt/caddy/caddy/caddymain/run.go:276 +0xd4
main.init()
	src/github.com/mholt/caddy/caddy/main.go:15 +0x44

Caddy starts fine without this plugin :

$ curl -Lsf 'https://caddyserver.com/download/linux/amd64?plugins=dns,http.authz,http.awslambda,http.cgi,http.cors,http.datadog,http.expires,http.filemanager,http.filter,http.git,http.gopkg,http.hugo,http.ipfilter,http.jwt,http.login,http.mailout,http.minify,http.prometheus,http.proxyprotocol,http.ratelimit,http.realip,http.reauth,http.upload,net,tls.dns.cloudflare,tls.dns.digitalocean,tls.dns.dnsimple,tls.dns.dnspod,tls.dns.dyn,tls.dns.exoscale,tls.dns.gandi,tls.dns.googlecloud,tls.dns.linode,tls.dns.namecheap,tls.dns.ovh,tls.dns.rackspace,tls.dns.rfc2136,tls.dns.route53,tls.dns.vultr' | tar -xvz caddy && ./caddy 
caddy
Activating privacy features... done.
http://:2015
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".

Caddy 0.11.0, compiled for armv7 with grpc-web plugin.

Steps to reproduce:

1. Start with example code from improbable-eng:
   https://github.com/improbable-eng/grpc-web/blob/master/example/ts/src/index.ts
2. Replace the call to queryBooks(); with a recursive call to
   if (status !== 14)
   getBook();
   Change IP to caddy's server IP.
3. Start grpc service (server)
4. Run caddy with config
   0.0.0.0:8080, localhost:8080 {
   }
   0.0.0.0:55552, localhost:55552 {
   grpc 10.0.4.32:9090 {
   backend_is_insecure
   backend_tls_noverify
   }
   }
   At this point, both the http server and grpc-web proxy is up.
5. Open browser and load index.html.
6. After ~1061 calls to getBook(), http server and grpc-web proxy will no longer respond. Specific number of requests (including index.html and bundle.js) until we get a return status of 14:
   1016,951,1061,1061,1061,1020,1016.
7. At this point, the caddy process is still running, but neither the http server or the grpc-web server works.
   getBook responds with:
   getBook.onEnd.status 14 all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:60000: socket: too many open files"
   

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

to

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.

Having added the gRPC plugin to a Caddyfile like this (ignore the proxying details, just keeping them for completeness's sake) —

172.16.10.166:7777, localhost:7777/ {
    proxy / http://192.168.30.251:8888 {
        transparent
        websocket
    }  
}
grpc 192.168.30.251:9999 {
    backend_is_insecure
}

— Caddy complains about Error during parsing: Unknown directive 'backend_is_insecure'. So it appears to swallow the grpc option as such (and yes, caddy -plugins does list http.grpc), but doesn't like the subsequent block.

This is with a custom Caddy binary built from this source:

package main

import (
    "github.com/caddyserver/caddy/caddy/caddymain"
    _ "github.com/pieterlouw/caddy-grpc"
)

func main() {
    caddymain.EnableTelemetry = false
    caddymain.Run()
}

Any pointers/ideas?

Hi, I'm a little confused.
my caddy config:

grpc.example.ir {
  tls off
  errors visible
  grpc my_service:50051 {
    backend_is_insecure
    backend_tls_noverify
  }
}

I'm using docker andmy_service is on the same network as caddy is.

my client code is:

conn, err := grpc.Dial("grpc.example.ir:80", grpc.WithInsecure())

using above code, I'm getting an error:

rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection closed

what address should I use here?

Any plan in supporting new caddy version?