Caddyfile.template incorrect configuration cause infinite redirect
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- docker-compose
- Domain
- devops, infrastructure
Research direction
Inspect proxy/Caddyfile.template at the referenced header_up lines and compare them with Caddy's reverse_proxy header defaults. Reproduce the request headers shown in the issue, then verify the configuration no longer causes the web frontend to return an infinite 301 redirect and that forwarded headers contain the expected values.
Written by the indexing model from the issue text.
Description
According to caddy's doc https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults
By default, Caddy passes through incoming headers—including Host—to the backend without modifications, with three exceptions:
- It sets or augments the X-Forwarded-For header field.
- It sets the X-Forwarded-Proto header field.
- It sets the X-Forwarded-Host header field.
For these X-Forwarded-* headers, by default, the proxy will ignore their values from incoming requests, to prevent spoofing.
But the Caddyfile.template set these two header incorrectly
Causing the web frontend received the following data, then frontend return 301 redirect to https://openproject.local:8043 infinitely.
Listening on 0.0.0.0 8080
Connection received on 10.89.3.6 58158
GET / HTTP/1.1
Host: openproject.local:8043
User-Agent: curl/8.14.1
Accept: */*
Via: 2.0 Caddy
X-Forwarded-For:
X-Forwarded-Host: openproject.local:8043
X-Forwarded-Proto:
Accept-Encoding: gzip
After remove these two header_up lines, reverse_proxy works as except:
Listening on 0.0.0.0 8080
Connection received on 10.89.3.7 59848
GET / HTTP/1.1
Host: openproject.local:8043
User-Agent: curl/8.14.1
Accept: */*
Via: 2.0 Caddy
X-Forwarded-For: 10.89.3.7
X-Forwarded-Host: openproject.local:8043
X-Forwarded-Proto: https
Accept-Encoding: gzip
- Dominant language
- Shell
- Stars
- 348
- Forks
- 320
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from opf/openproject-docker-compose
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
opf/openproject-docker-compose#165 · 2 reactions ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
opf/openproject-docker-compose#150 · 6 comments · 5 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
All issues in opf/openproject-docker-compose
Similar issues
-
area:docs phase:release priority:p0 type:test
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
-
Non-root first start logs "Base venv updated (stamp mismatch)" instead of the first-run messageOpenarea: infrastructure bug priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
snapotter-hq/SnapOtter#4573 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
eip-work/kuboard-press#700 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
fullsend-ai/agents#1901 ·
Maintainers usually reply within 1 day