HTML post-processor for caddy?

Help
1

1. The problem I’m having:

I want to post-process HTML output, but I’m having trouble locating the proper syntax or plugin/extension for caddy. I just want to post-process HTML output on one sub-route of a reverse-proxied service. A generic way to pipe through a custom tool would be fine, or something such as a regular-expression matcher/replacer would also work.

2. Error messages and/or full log output:

3. Caddy version:

v2.7.4 h1:J8nisjdOxnYHXlorUKXY75Gr6iBfudfoGhrJ8t7/flI=

4. How I installed and ran Caddy:

a. System environment:

Ubuntu 22.04.3 LTS

b. Command:

ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

c. Service/unit/compose file:

d. My complete Caddy config:

satoshidnc.com {
        handle /.well-known/nostr.json* {
                rewrite /.well-known/nostr.json* /nostrnip5/api/v1/domain/YLrr9Lhocdtr79EhwBkrzE/nostr.json
                reverse_proxy 0.0.0.0:5000 {
                        header_up X-forwarded host satoshidnc.com
                }
        }
        handle /message {
                reverse_proxy 0.0.0.0:9091 {
                        header_up X-forwarded host satoshidnc.com
                }
        }
        handle_path /* {
                root * /var/www
                try_files {path} /index.html
                file_server
        }
        handle {
                # Fallback for any request not otherwise handled
        }
}
ng.satoshidnc.com {
        handle_path /* {
                root * /var/www/posse
                try_files {path} /index.html
                file_server
        }
        handle {
                # Fallback for any request not otherwise handled
        }
}
mercado.satoshidnc.com {
        handle / {
                rewrite / /nostrmarket/market
        }
        reverse_proxy 0.0.0.0:5000 {
                header_up X-forwarded host satoshidnc.com
        }
}
lnbits.satoshidnc.com {
        handle /api/v1/payments/sse* {
                reverse_proxy 0.0.0.0:5000 {
                        header_up X-forwarded host satoshidnc.com
                        transport http {
                                keepalive off
                                compression off
                        }
                }
        }
        reverse_proxy 0.0.0.0:5000 {
                header_up X-forwarded host satoshidnc.com
        }
}
relay.satoshidnc.com {
        reverse_proxy 0.0.0.0:7777 {
                header_up X-forwarded host satoshidnc.com
        }
}

5. Links to relevant resources:

2

Does the templates handler do what you want?

In order for us to help you might need to be more specific about what you’re trying to do.

3

That looks sufficiently flexible. Could you tell me how to properly enable it in my Caddyfile? I want it to apply to all HTML output under a particular prefix (/nostrmarket/market in this case).

4

Literally just templates /nostrmarket/market/*

(Am mobile, sorry, and my keyboard doesn’t even have backtick key :triumph:)

5

Thank you but I tried literally that, and also the following variation, but my test string was not replaced in the rendered page:

mercado.satoshidnc.com {
  templates
  handle / {
    rewrite / /nostrmarket/market
  }
  reverse_proxy 0.0.0.0:5000 {
    header_up X-forwarded host satoshidnc.com
  }
}

The test string is:

{{`1`}}

…which I expect should become just a plain 1.

6

What is the Content-Type header of the response?

7

The Content-Type is ok, and when I moved the template test to the HTML source it worked, so everything Caddy-side is working now as it should. Thank you for your support, and this is probably something I will make good use of in the future, although unfortunately where I needed the template string today is in a dynamically generated part of the page, so I will have to re-think how to solve the problem for my current use case.

8

Some feedback:

This doesn’t do what you think it does. It tries to replace the value of the X-Forwarded header (which isn’t a thing) by searching for the value host and replacing it with satoshidns.com. So effectively, it does nothing. You can probably remove this everywhere.

Using 0.0.0.0 only kinda works “by coincidence”. The IP 0.0.0.0 isn’t a real thing, it means “all interfaces” and is typically used for listen addresses, but as a connection address it happens to connect to “localhost” purely due to a implementation decision by the Linux network stack. See networking - Connecting to IP 0.0.0.0 succeeds. How? Why? - Unix & Linux Stack Exchange. I recommend using 127.0.0.1 or localhost just for clarity’s sake.

These blocks are sorta contradictory. handle_path /* will match every request because all URL paths start with /. So you can just remove the _path /* part of the first block and delete the second handle block and it’ll work the same, with less config.

This can be simplified, you can remove the handle because your rewrite already has the / matcher on it.

Are you sure you need this? :thinking:

2 Likes
9

Thank you! Your explanations and suggestions are much appreciated!

On that last transport http block, I can only say I think it has to do with the fact that it applies to an API, and the API needs certain behavioral characteristics. I can’t say exactly why at the moment.

1 Like
10

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