Specific http methods handling

1. Caddy version (caddy version):

v2.1.1

2. How I run Caddy:

caddy run --config /etc/caddy/Caddyfile

a. System environment:

ubuntu

d. My complete Caddyfile or JSON config:

    :9200 {
        
        reverse_proxy 0.0.0.0:9201

        @deletefoo {
            method DELETE
            path *
        }

        ????? reverse_proxy @deletefoo google.com

        log {
            output file /var/log/caddyserver/caddy.log {
                    roll_size 1gb
                    roll_keep 5
                    roll_keep_for 7200h
            }

    }

3. The problem I’m having:

I am running a server, I want to “reverse_proxy” everything but block anything that is a DELETE http method.
I came up with the above half working (causes 500 errors on DELETE) but I would like to instead use “respond” to send some static text.
Any suggestions on that?

4. Error messages and/or full log output:

5. What I already tried:


6. Links to relevant resources:

Should just be this:

@blockDelete method DELETE
respond @blockDelete "Nope" 400

I would say 400 is more appropriate than 500 here. 500 implies something went wrong on the server, 400 implies the client made a bad request.

2 Likes

Perfect, exactly what I was after… as a side note, I will say that I think there is by now a huge confusion of complete end to end examples of Caddy, how to do X requires allot of searching.
But this one instance, exactly what I needed, thanks.

I’m not sure I understand where your confusion stemmed from. Think you could explain? Reading your original post, it looked like you had all the pieces but weren’t able to put them together. What misled you?

Francis, great question!

Coming from nginx config, the caddyfile config feels unnatural to me so far. But i have never stopped to read the docs cover-to-cover (I was hoping I don’t need to do that).

I am still a bit confused about the exact syntax between a named matcher and the “action” part.
What are the valid actions?
I used reverse_proxy, you used respond, any other options? what are all the group of such “actions” ? do they have a name I can search for?

Thinking about procedural languages here, when I “respond” or “reverse_proxy” does the request still being processed afterwards?

What type of values can be inside the “matcher” and what can only be outside, e.g. the full and complete schema of a caddyfile (is there a caddyfile linter)?

btw - the “log” item in the config is still not working for me, this is a copy pasted example from the docs.

They’re called “directives”:

Not all directives support matchers, only those that are HTTP handlers do. Some, like tls, are essentially site-wide config and can’t have matchers. Some are also shortcuts to a matcher+handler combo, like try_files, so it’s not viable to support matchers for that (because the merging logic would be non-trivial). It’s noted in the syntax doc for each directive whether they support matchers.

It depends. HTTP handlers work in a middleware pipeline, ordered by the directive order (found at the bottom of the page linked above; but this can be overriden). Some handlers can be terminal (i.e. prevent other handlers from doing anything after that one).

The matcher docs are here, as I’m sure you’ve already found:

Named matchers are essentially a set of conditions that apply to a directive, determining if it should apply to any given request.

There’s a Caddyfile Structure diagram on this page, with all the other basic concepts about the Caddyfile syntax:

I think you might be missing a closing }, looking at your Caddyfile in the top post? What does your Caddyfile look like now? It’s hard to tell what might be wrong without knowing exactly what your config looks like now.

Make sure your permissions allow for that location to be written to by the caddy user, if you’re running it as a service. If running as your local user, make sure that user has permissions to write there.