Caddy v2 exclude gzip for a path

Help
1

1. Caddy version (caddy version):

v2.0.0 and v2.1.0-beta

2. How I run Caddy:

N/A

systemd on Ubuntu 18.04 with caddy run

d. My complete Caddyfile or JSON config:

I have redacted the domain name as I do not want these forum posts showing up in searches for my client’s domain.

misspelled.com {
    redir https://example.com{uri} permanent
}

staging.example.com {
    redir https://beta.example.com{uri} permanent
}

beta.example.com {
    log {
        output stdout
        format console
    }
    encode gzip zstd
    reverse_proxy /api/* localhost:3001
    @notApi {
        file {
            try_files {path} {path}/ /index.html
        }
        not path /api/*
    }
    route {
      rewrite @notApi {http.matchers.file.relative}
    }
    root * /home/me/example.com/build/
    file_server
}

3. The problem I’m having:

I’d like to exclude encode gzip zstd from a certain webhook path.

This is because either there is a bug in Caddy v2 and it is sending an improper type of gzip or zstd, or there is a bug in the webhook service (pandadoc) by which it is requesting compression, but not understanding the mutually selected compression.

I’ll be checking logs to try to find out which were the request and response headers in hopes of determining which encoding was selected, and if flipping the preferred order (i.e. encode zstd gzip instead of encode gzip zstd) makes a difference.

4. Error messages and/or full log output:

(will post back when I’ve found and captured these)

5. What I already tried:

I’ve tested with curl --compress and I seem to get the results I expect, which leads me to believe that it is not an issue with Caddy.

For now I’ve just removed encode gzip zstd entirely.

6. Links to relevant resources:

N/A

2

Hey AJ :wave:

You can do something like this:

@notWebhook {
    not path /webhook/*
}
encode @notWebhook gzip zstd
1 Like
3

Am I to take it that the @whatever applies liberally to pretty much all modules then?

I thought that it was just for rewrites.

Thank you very much Matt!

2 Likes
4

Look at the docs for each directive:

If they mention [<matcher>] in the syntax, then they support request matching. If they don’t, they don’t. Most do though.

3 Likes
5

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