Redirect wrong scheme:port https://site:80

[Maxiride (CircuitDuck)]

1. The problem I’m having:

Apparently an upstream service has a bug that results in an incorrect origin.

API calls are being made to https://mysite.net:80, obviously this results in an SSL error.

2. Error messages and/or full log output:

An inevitable SSL error.

3. Caddy version:

lucaslorentz/caddy-docker-proxy:2.8.10

d. My complete Caddy config:

mysite.net {
   reeverse_proxy internal_address:7000
}

---

Meanwhile, while we wait to see if the upstream team can fix the issue I’m fiddling around to see if we can work around the issue on our side.

How can I intercept such wrong calls and rewrite the request so that if the scheme https and port 80 are used it is rewritten correctly?

So far I’ve been running in circles.

[Whitestrake (Matthew Fay)]

There’s a few approaches I can think of.

Caddy can alter HTTP responses midstream with GitHub - sjtug/caddy2-filter: Replace response body in caddy2 or GitHub - caddyserver/replace-response: Caddy module that performs replacements in response bodies. These require uncompressed responses from the backend.

Caddy can also intercept and replace headers from upstream via header_down: reverse_proxy (Caddyfile directive) — Caddy Documentation

Both of those approaches are based on the assumption that your API clients are coming from HTTP / javascript served via Caddy, and that you can locate to effectively isolate and replace those bad responses.

You could also go for the ultimate jank of serving HTTPS on port 80. This is Wrong™, and Caddy will try to stop you from doing this by default, so you’d need to move HTTP off port 80 with the http_port global option. This will change the HTTP port (and therefore the redirect listener) for the whole server, so be aware, but it will let you listen on https://:80 and handle that however you please. I think better than that, though, would honestly be putting a layer 4 proxy in front to intercept HTTPS on port 80 and redirect it to 443, leaving Caddy’s HTTP server operating normally.

[Maxiride (CircuitDuck)]

I’m sorry, indeed I didn’t specify the direction of the requests, the content isn’t served from Caddy. It originates from another server.

Binding 80 for HTTPS is a no-go since many other services are running it would affect to much stuff with potential issues.

[Whitestrake (Matthew Fay)]

If the API client is a browser served scripts from another server, then Caddy can’t do anything to correct the outgoing links.

If Caddy can’t listen to HTTPS on port 80, then Caddy can’t do anything to accept the incoming requests.

You would be, therefore, at a deadlock unless you can put another listener in front of Caddy’s httpserver, to intercept the bad traffic and redirect it to the right place.

GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy might be able to do this for you.