Redirecting http and https requests to different ports

[amdavidson]

I am trying to put snikket behind an existing caddy-docker-proxy install. Snikket supports being proxied but I'm having a hard time translating it to the label format.

I do not see a configuration example or previous issue indicating how one would redirect http and https requests to the underlying containers separately. If i just use {{upstreams}} I get an endless 301 redirect loop.

Is this a supported use case?

services:
  snikket_proxy:
    container_name: snikket-proxy
    image: snikket/snikket-web-proxy:stable
    env_file: snikket.conf
    volumes:
      - ./data:/snikket
      - acme_challenges:/var/www/html/.well-known/acme-challenge
    restart: "unless-stopped"
    networks:
      - caddy
    labels:
      caddy: chat.amd.im, groups.chat.amd.im, share.chat.amd.im
      caddy.0_reverse_proxy: "{{upstreams http 80}}"
      caddy.1_reverse_proxy: "{{upstreams https 443}}"

[francislavoie]

You don't need to specifically handle HTTP. Caddy redirects all HTTP requests to HTTPS automatically, which is the secure default. Proxy to your upstream app over HTTP only, not HTTPS.

[amdavidson]

That would be a typical recommendation, sure.

Snikket specifically doesn't support this yet... it's been on the list since 2023 at least. The HTTP listener redirects to HTTPS, which then gets turned back into HTTP from the caddy proxy and the cycle repeats.

I could forward the request to the HTTPS listener, but then snikket needs to be able to handle .well-known on port 80 to get keys from lets encrypt.

If this isn't possible via the caddy proxy, I'm going to have to do a custom snikket container, which would be a maintenance burden I would prefer not to add.

[lucasff]

@amdavidson it seems Snikket is taking over the proxying part, and wants to terminate the SSL certificate. I'm pretty sure there's a config somewhere that disables this behaviour.