[Question] List of events

[KaKi87]

Hello,

The README uses cert_obtained as an example event but what other events are available ?

And specifically, what's the event for an HTTP request ?

Thanks

[mholt]

It's hard to give a proper list because each module emits their own events, and modules are pluggable. i.e. we don't control the events that are emitted.

There are some standard ones that are pretty common, especially related to TLS automation -- I'd recommend reading the logs for now, until we figure out a way to document the events.

This PR describes most of them for now, I think: caddyserver/caddy#4912

[KaKi87]

I see no event name in the logs for a request, it's just <date> <hostname> <process>[<pid>]: <json> (and the linked PR doesn't show one either) ?

Thanks

[mholt]

There's no event for HTTP requests... there are detailed access logs though. Usually people implement an HTTP handler module for custom HTTP request behavior.

[KaKi87]

My use case is server-side analytics, so I'd like to run a script every time Caddy receives a request, without proxying or altering that request in any way.
Thanks

[mholt]

Definitely write an http handler module instead; it will perform much better!

[KaKi87]

without proxying or altering that request in any way

[mholt]

Yeah. So write a handler. Don't proxy it or alter anything. (I assume you mean alter not alert)

[KaKi87]

I guess I don't understand what you mean. Could you please explain ? Thanks

[mholt]

Sure -- there's an example on the bottom of this page, which explains how to extend Caddy: https://caddyserver.com/docs/extending-caddy

Running a command at every HTTP request will affect requests more than an HTTP handler, which is basically your code that then calls next.ServeHTTP() to pass the request along to the next handler. It's all in process. No proxying, no need to modify the request.

[KaKi87]

Thanks, but I want to write that script in Bash, not Go 😅

[mholt]

Then either read the logs in bash, or write a handler to emit an event on HTTP requests. We don't do this already because running a command on every HTTP request is not very performant and can open the door to DoS.