On: The future of Nginx: Getting back to our open source roots

[francislavoie]

Caddy is designed around pluggability, everything is a module. It's written in Go, so you write your middleware logic in Go. See https://caddyserver.com/docs/extending-caddy

[Starlevel001 → francislavoie]

Interesting way of saying "no"

[francislavoie → Starlevel001]

Maybe you can better explain what they're asking for. Because otherwise, I find it unclear. Isn't the point of OpenResty to provide a system for building your app right inside the webserver? Because you can absolutely do that with Caddy, by writing plugins.

[js2 → francislavoie]

Here's an example of how I'm using it. Basically to log part of the response body to API requests.

    log_format  main  '$remote_addr - - [$time_local] "$request" '
                      '$status $body_bytes_sent "$host" '
                      '"$http_user_agent" $http_content_length $request_time '
                      '"$resp_body" *$connection $connection_requests';

    server {
        set $resp_body "";
        location ~ "^/api/v1/...$" {
            # Append response to resp_body until it reaches max_len.
            # - ngx.arg[1] is input chunk.
            # - ngx.arg[2] is eof flag (response is done).
            # - ngx.ctx.resp_body holds partial result between calls
            # - ngx.var.resp_body holds final result.
            # From:
            # - https://gist.github.com/morhekil/1ff0e902ed4de2adcb7a
            # - https://github.com/openresty/lua-nginx-module/
            body_filter_by_lua_block {
                local max_len = 256
                local resp_body = (ngx.ctx.resp_body or "")
                if string.len(resp_body) <= max_len then
                    resp_body = resp_body .. string.sub(ngx.arg[1], 1, max_len)
                    ngx.ctx.resp_body = string.sub(resp_body, 1, max_len)
                end
                if ngx.arg[2] then
                    ngx.var.resp_body = ngx.ctx.resp_body
                end
            }
    }

But there are many scenarios where being able to extend the HTTP server via Lua is more convenient than writing a plugin I would think?

I've also used Lua in the past with haproxy and with Redis. It's a powerful, performant, light-weight, and flexible escape hatch/extension mechanism.

[francislavoie → js2]

> But there are many scenarios where being able to extend the HTTP server via Lua is more convenient than writing a plugin I would think?

Well, Caddy is written in Go, so it's only natural to write a plugin in Go. Statically compiled into your binary. We provide a tool called `xcaddy` which is used to produce builds of Caddy with any plugins you need. You just need Go installed on your system to run it, no other dependencies.

The reason why Lua is used for OpenResty is because writing plugins in C is... not fun.

You can absolutely do what you described with an HTTP handler module in Caddy. You'd just wrap the req.Body with a reader that watches the bytes as they're copied through the stream, and when you see the part you want to log, you do that.

We have a replace-response plugin which takes a similar approach, except it manipulates the response as it's being streamed back to the client. https://github.com/caddyserver/replace-response The whole plugin is just one file of Go code.

[js2 → francislavoie]

Thanks for the reply.