Caddy: Caddy in HTTP mode behind other HTTPS proxy

[schnatterer]

1. Which version of Caddy are you using (caddy -version)?

Caddy 0.11.5 (+80dfb8b Mon Mar 11 12:28:49 UTC 2019) (unofficial)
7 files changed, 3 insertions(+), 2 deletions(-)
.github/PULL_REQUEST_TEMPLATE/pull_request.md
caddy.go
caddy/caddymain/run.go
caddyhttp/proxy/proxy.go
caddyhttp/proxy/proxy_test.go
caddyhttp/proxy/upstream.go
caddyhttp/proxy/upstream_test.go

Basically include plugins http.login and http.jwt and disable telemetry.

See this Dockerfile for more details.

2. What are you trying to do?

I have Caddy running behind another Reverse Proxy which already takes care of HTTPS and (for performance reasons) I'd like to use a plain HTTP connection between the reverse proxy and caddy.
This works for direct URL requests, but redirects are always returned to http:// instead to https://.

3. What is your Caddyfile?

{$HOST} {
gzip
log stdout
#redir https://{hostonly} #Leads to redirect loop

proxy / localhost:4567 {
  transparent
}


#tls self_signed

jwt {
    path /
    redirect /login
    allow sub myuser
}

login {
    success-url /
    jwt-expiry 720h
    htpasswd file=/gollum/config/.htpasswd
    jwt-secret {$JWT_SECRET}
}
}

Where Set the env var HOST="http://*"

4. How did you run Caddy (give the full command and describe the execution environment)?

For what concers caddy it's pretty much only

• -conf /gollum/config/Caddyfile
• and the two env vars
  
  
  
  • HOST="http://*" and
  
  
  • JWT_SECRET=<512chars>
  
  

In case it helps for reproducing, here's the full docker command:

````
docker run \

• p8080:80 \
  -e GOLLUM_PARAMS="--allow-uploads --show-all" \
  -e CADDY_PARAMS="-conf /gollum/config/Caddyfile" \
  -e HOST="http://*" \
  -e JWT_SECRET="<512 random chars>" \
  -v :/gollum/config \
  -v gollum-vol:/gollum/wiki \
  schnatterer/gollum-galore:0.4.0
  ````

5. Please paste any relevant HTTP request(s) here.

When having another proxy (nginx in my case) redirecting to http://localhost:8080, the requests look as follows

REQ: https://my-doma.in
RESP 302 http://my-doma.in/Home

Interesting: When not logged in, the redirect from / to /login are redirected to https:// as expected.
After logging in the redirects from / to /Home and the other redirects from the system that is proxied by Caddy (gollum) are redirected to http.

6. What did you expect to see?

I'd expect to have redirects on the same protocol as the original query.
Or any option to configure this?

REQ: https://my-doma.in
RESP 302 http://my-doma.in/Home

7. What did you see instead (give full error messages and/or log)?

No errors in the log.

8. Why is this a bug, and how do you think this should be fixed?

Isn't it a usual to run HTTP behind a HTTPS reverse proxy?
There should be some way of configuring it, either intuitive or documented.
Or if Caddy is not intented for this use case (why so ever) it would be helpful to find this info in the docs.

9. What are you doing to work around the problem in the meantime?

Using a self signed cert which drastically slows performance (really small hardware) and in addition being forced to use an older version of caddy because of #2502.

10. Please link to any related issues, pull requests, and/or discussion.

I tried redir https://{hostonly} as stated in #728, which lead to an infinite redirect loop.
Also tried

redir 301 {
    if {>X-Forwarded-Proto} is http
    /  https://{host}{uri}
}

which didn't change a previous redirect to http://.

Bonus: What do you use Caddy for? Why did you choose Caddy?

For bringing Auth (and optional HTTPS, obviously not in the case described in this issue) to a Ruby app gollum.
See gollum-galore.

Why caddy: See decision doc of gollum-galore

[francislavoie]

This sort of usage questions should be asked on https://caddy.community

Have you tried tls off? Also, it's unclear what redirects you're asking about - if the redirects are coming from a proxied service, then that service should be aware of the X-Forwarded-Proto header as to keep it the same.

[tobya]

If you only serve in http then requests will not be serverd via https

http://example.com { root c:\myhttpsite\ }

[schnatterer]

@francislavoie thanks for your fast answer.
Do I close this now and reopen on community?

Anyways, no change in behaviour with HOST=https://* and tls off except that I now have HTTP on Port 443 :-P

The X-Forwarded-Proto header is a good point. I had a look into the communictation between Caddy and its backend (gollum) and found out that Caddy passes on X-Forwarded-Proto: http.

I now have a workaround: header_upstream X-Forwarded-Proto https works around my problem! Thanks for pointing me!

Is there a way I can fix this in a more versatile way, i.e. like forcing X-Forwarded-Proto https only when Caddy receives a X-Forwarded-Proto https header itself?

So, generally, we could close this issue; but as to

1. Why is this a bug, and how do you think this should be fixed?

Wouldn't it make sense that caddy passes the X-Forwarded- headers it receives (if present) upstream (i.e. to its backend)?

[francislavoie]

The transparent preset on proxy does exactly that, see the docs: https://caddyserver.com/docs/proxy

If Caddy is passing http, then it's because whatever proxy you have fronting Caddy isn't passing along the correct scheme.

I'll close this now since it doesn't seem like an issue, just a configuration question. We can continue to discuss here or you can open a thread on the forum if you still need more help.

Edit: Oh, maybe it's because Caddy doesn't forward X-Forwarded-Proto but rather the scheme of the incoming connection. I think the solution would be to set header_upstream X-Forwarded-Proto {>X-Forwarded-Proto}. That might work.

[schnatterer]

@francislavoie
Fair enough, I'm happy with the workaround and I don't need more help. Thanks again!

I could definitely see via ngrep that Caddy received a X-Forwarded-Proto : https from the nginx reverse proxy and passed on a X-Forwarded-Proto : http to gollum. I had transparent set in the Caddyfile and adding header_upstream X-Forwarded-Proto https fixed the problem for me.

It would be more convenient (especially for others) if caddy contained a logic that checked any incoming X-Forwarded-Proto headers instead of just the scheme of the incoming connection 😛

Anyways, we have a workaround and obviously no one else has stumbled upon this. So it's probably low prio or can stay closed. Your call. Cheers! 😉