Problem after upgrading to 2.7.2

Help
1

1. The problem I’m having:

Caddy’s response skips first few characters:

2. Error messages and/or full log output:

❯ curl -s https://badti.me/.well-known/matrix/server |hexdump -C
00000000  73 79 6e 61 70 73 65 2e  62 61 64 74 69 2e 6d 65  |synapse.badti.me|
00000010  3a 34 34 33 22 7d                                 |:443"}|
00000016

3. Caddy version:

2.7.2

4. How I installed and ran Caddy:

a. System environment:

FreeBSD 13.2 (amd64), FreeBSD ports

b. Command:

service caddy restart

c. Service/unit/compose file:

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

d. My complete Caddy config:

{
        preferred_chains smallest
        #       auto_https disable_redirects
        servers :443 {
                protocols h1 h2 h3
                timeouts {
                        read_body 30s
                        read_header 30s
                }
        }

        acme_ca https://acme-v02.api.letsencrypt.org/directory
        #       acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
        email user@example.net
        key_type rsa4096
}

(redirect) {
        @http {
                protocol http
        }
        redir @http https://{host}{uri}
}

(matrix-well-known-header) {
        # Headers
        header {
                Access-Control-Allow-Origin "*"
                Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
                Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization"
                Content-Type "application/json"
        }
}


(matrix) {
        handle /.well-known/matrix/server {
                import matrix-well-known-header
                respond `{"m.server":"{args.0}"}`
        }
        handle /.well-known/matrix/client {
                import matrix-well-known-header
                respond `{"m.homeserver":{"base_url":"https://{args.0}"}}`
        }
}

(basic-config) {
        tls {
                key_type p384
        }
        import headers
        import robots
}

(headers) {
        header {
                Content-Security-Policy "frame-ancestors 'none'";
                X-Frame-options "DENY"
                X-Content-Type-Options "nosniff"
                X-XSS-Protection "1; mode=block"
                Referrer-Policy "no-referrer" # strict-origin-when-cross-origin"
                Strict-Transport-Security "max-age=31536000;"
                Permissions-Policy "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=(), interest-cohort=()"
                X-Robots-Tag "none"
                -server
        }
}


(robots) {
        header /robots.txt {
                Content-Type "text/plain"
        }
        respond /robots.txt 200 {
                body "User-agent: *
Disallow: /
"
                close
        }

        @bot {
                header User-Agent *bot*
        }
        respond @bot 410 {
                body "And then there were none!"
                close
        }
}

badti.me:443 {
        import basic-config
        import matrix "synapse.badti.me:443"
        handle / {
                header Content-Type "text/plain; charset=utf-8"
                respond "Having a bad time ?"
        }
        log {
                output file /var/log/caddy/badti.me.log {
                        roll_size 1M
                        roll_keep 30
                }
                format json
        }
}

5. Links to relevant resources:

2

Works for me:

$ curl -s https://badti.me/.well-known/matrix/server
{"m.server":"synapse.badti.me:443"}
3

Ha, I tried the exact same thing at the exact same time, it works for me too:

{“m.server”:“synapse.badti.me:443”}

4

Hi,

Please excuse me, unless you tried to reproduce in your custom configuration, I implemented following workaround on my site for now:


(matrix) {
        handle /.well-known/matrix/server {
                import matrix-well-known-header
                respond "{\"m.server\":\"synapse.badti.me:443\"}"
#               respond `{"m.server":"{args.0}"}`
        }
        handle /.well-known/matrix/client {
                import matrix-well-known-header
                respond "{\"m.homeserver\":{\"base_url\":\"https://synapse.badti.me:443\"}}"
#               respond `{"m.homeserver":{"base_url":"https://{args.0}"}}`
        }
}
1 Like
5

I’ve reverted the workaround on my site, so you should be able to reproduce the problem now.

1 Like
6

Oh I see. I was able to reproduce it locally.

It only happens when the placeholder is used in a snippet.

Minimal reproducer:

(matrix) {
    respond `{"m.server":"{args.0}"}`
}

localhost {
    import matrix "synapse.badti.me:443"
}

$ curl -v "https://localhost/"

@WeidiDeng might have an idea :blush:

7

I think if you simply escape the first { it should work as well. So:

(matrix) {
    respond `\{"m.server":"{args.0}"}`
}

We’ll look to fix this soon, but we’re not in a rush because there’s viable workarounds for the moment. Thanks for reporting!

P.S. {args.0} is deprecated, you should use {args[0]} now. See your logs, there should be a warning about that in there.

2 Likes
8

Thank you!

9

Can you try xcaddy build fix-args-replacer to see if the problem is solved?

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.