The Wayback Machine - https://web.archive.org/web/20201123191102/https://github.com/valeriansaliou/vigil/issues/52
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caddy reverse proxy #52

Open
L1Cafe opened this issue Apr 6, 2020 · 0 comments
Open

Caddy reverse proxy #52

L1Cafe opened this issue Apr 6, 2020 · 0 comments
Labels
bug

Comments

@L1Cafe
Copy link

@L1Cafe L1Cafe commented Apr 6, 2020

I'm not very experienced with Caddy, because for now, I've always resorted to simply using Nginx, however I'm finding some difficulties when setting up Caddy and Vigil.

To check that it wasn't Caddy's fault, I have also tried to reverse proxy other webpages, and everything seemed to work perfectly fine.

And to be perfectly clear, serving Vigil over port 8080 (HTTP only) also works perfectly fine, both dialing the IP as well as using the hostname (although most web browsers refuse to connect because HSTS is enforced, I checked this using cURL which doesn't observe HSTS).

I use the following settings in vigil.cfg to serve on port 8080:

inet = "0.0.0.0:8080"

Initially, my Caddyfile looked like this:

status.hostname.com

reverse_proxy / {
	to http://localhost:8080
}

(I replaced my actual domain with hostname.com).

According to Caddy's documentation, it passes on all original headers unmodified to the upstream server. Since I suspected there may be an issue with the Host header, I modified the Caddyfile as so:

status.hostname.com

reverse_proxy / {
	to http://localhost:8080
	header_up Host localhost
	header_up -Upgrade-Insecure-Requests
	header_up -Pragma
	header_up -Cache-Control
}

However, it unfortunately still does not work, and I'm not sure at this point whether or not this is my fault, Caddy's, or Vigil's.

The relevant fragment of logs from Caddy looks like this:

(DEBUG) - Incoming stream
(DEBUG) - Request Line: Get AbsolutePath("/status/text/") Http11
(DEBUG) - Headers { Host: aa.bb.cc.dd:8080
, Connection: keep-alive
, User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36
, DNT: 1
, Accept: */*
, Referer: http://aa.bb.cc.dd:8080/
, Accept-Encoding: gzip, deflate
, Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
, }
(INFO) - GET /status/text/:
(INFO) - Matched: GET /status/text (status_text)
(INFO) - Outcome: Success
(DEBUG) - writing head: Http11 Ok
(DEBUG) - headers [
Headers { Content-Type: text/plain; charset=utf-8
, Server: Rocket
, Content-Length: 7
, Date: Mon, 06 Apr 2020 17:57:41 GMT
, }]
(DEBUG) - write 7 bytes
(INFO) - Response succeeded.
(DEBUG) - keep_alive = true for xx.yy.zz.ww:58157
(DEBUG) - ioerror in keepalive loop = Custom { kind: UnexpectedEof, error: "end of stream before headers finished" }
(DEBUG) - keep_alive loop ending for xx.yy.zz.ww:58157
@valeriansaliou valeriansaliou added the bug label Apr 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.