https reverse proxy does not work with only port specified

[wlnirvana]

The doc says:

Specifying ports 80 and 443 are the same as specifying the HTTP and HTTPS schemes, respectively.

However, the following configs don't work

gh.proxy.mydomain.com {
  reverse_proxy github.com:443 {
    header_up Host {upstream_hostport}
    header_up X-Forwarded-Host {host}
  }
}

gh.proxy.mydomain.com {
  reverse_proxy github.com {
    header_up Host {upstream_hostport}
    header_up X-Forwarded-Host {host}

    transport http {
      tls
    }
  }
}

Only the following two work:

gh.proxy.mydomain.com {
  reverse_proxy https://github.com {
    header_up Host {upstream_hostport}
    header_up X-Forwarded-Host {host}
  }
}

gh.proxy.mydomain.com {
  reverse_proxy github.com:443 {
    header_up Host {upstream_hostport}
    header_up X-Forwarded-Host {host}

    transport http {
      tls
    }
  }
}

Caddy version

root@VM-8-7-debian:/etc/caddy# caddy version
v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

[mholt]

Hmm, it wouldn't surprise me if this was some regression, as the Caddyfile parsing here is rather complex.

Some relevant history:

• https://github.com/caddyserver/caddy/commit/c83d40ccd43c8692061732974bd02fb388acd425
• https://github.com/caddyserver/caddy/commit/260982b2dfc2cbf30c9b6e3a06f54e589344fc41

(I'm only intermittently available this week, if someone else wants to look more closely before I get a chance. Or I will eventually!)

[francislavoie]

The doc is technically misleading I guess, but yeah I recommend using https:// for the shortest config.

The default port is 80 and the default transport is http. Changing either of those in isolation doesn't change the other, and I don't think it really should. I think the behaviour is okay, but the docs can be clarified.

[RussellLuo]

I agree with Francis. Technically, the URI scheme ("http" or "https") has no relationship with the TCP port. Therefore, in my opinion, both http://example.com:443 and https://example.com:80 are technically valid, although unconventional.

I even find a RFC that has proposed to use 80 for secured HTTP:

This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).

[mholt]

Ok yeah I think I agree with Francis. Scheme implies a (default) port and protocol, whereas just a port isn't enough. Maybe we should just remove that from the docs. Using https:// seems sufficiently easy, equal to specifying the port.

[wlnirvana]

The doc is technically misleading I guess, but yeah I recommend using https:// for the shortest config.

The default port is 80 and the default transport is http. Changing either of those in isolation doesn't change the other, and I don't think it really should. I think the behaviour is okay, but the docs can be clarified.

Yeah specifying the scheme is apparently the easiest way to do so, but placeholders are not allowed to be mixed with schemes due to parsing difficulties, that's was why I experimented with different setups (and ended up with port + transport).

[mholt]

Fixed the docs. Thanks for bringing up the discussion!