GitHub reverse proxy fails to pass POST request properly

[wlnirvana]

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

a. System environment:

root@VM-8-7-debian:/etc/caddy# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye
root@VM-8-7-debian:/etc/caddy# uname -a
Linux VM-8-7-debian 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

b. Command:

caddy run

c. My complete Caddyfile or JSON config:

github.com.my.host.name {
  log {
    level debug
  }
  reverse_proxy https://github.com {
    header_up Host {upstream_hostport}
    header_up X-Forwarded-Host {host}
    header_up X-Forwarded-Ssl on
    # header_up X-Real-IP {http.request.remote}
    # header_up X-Forwarded-For {http.request.remote}
    # header_up X-Forwarded-Port {http.request.port}
    # header_up X-Forwarded-Proto {http.request.scheme}
    # header_up X-Url-Scheme {http.request.scheme}
  }
}

3. The problem I’m having:

GET request works, but POST request (login, signup, etc) returns 422 status code.

[francislavoie]

What you’re looking for is a forward proxy, not a reverse proxy.

A reverse proxy is typically used in situations where you need to send a request to another server in your control. Github probably doesn’t handle being reverse-proxied to.

[wlnirvana]

I want to provide a “transparent” proxy to my clients that requires no machine-specific configuration except changing the URL, thus a reverse proxy is needed.

Is it possible to log outgoing requests (like headers, or even payloads) made by the reverse proxy module so that I can debug whether the root cause is github or caddy config?

[francislavoie]

Yes, add the debug global option. You’ll see more details about the proxy traffic.

Request/response bodies, not easily. Debugging payloads is inefficient because Caddy streams the request body to the upstream, it doesn’t buffer it.

[wlnirvana]

It seems overriding the origin header helps.

header_up origin https://github.com

There are still some other issues, though. But I guess the root cause is github instead of caddy.

[wlnirvana]

Alright. To further handle redirects, one more directive is needed

header_down location (https://github.com/)(.*) https://github.com.my.host.name/$2

However, this still will not completely save you from GitHub’s captcha mechanism when signing up a new account. GitHub serve’s its captcha from octocaptcha.com service, which sends a header like the following:

content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; connect-src api.funcaptcha.com api.arkoselabs.com; form-action 'none'; frame-ancestors github.com *.github.com *.githubapp.com; frame-src api.funcaptcha.com api.arkoselabs.com; script-src api.funcaptcha.com api.arkoselabs.com cdn.arkoselabs.com 'unsafe-eval' github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com

Being a reverse proxy at github.com.my.host.name, your browser will not handle this captcha due to security concerns.

So back to square one