Caddy: v2: Add the request_id placeholder

[danlsgiga]

Having a request_id placeholder would be cool to allow some tracing on distributed http calls among multiple upstreams. Same functionality that was provided by https://caddyserver.com/v1/docs/request_id in v1

[mholt]

Ah yes, this will probably be implemented along with the rest of Caddy's tracing features.

[lolPants]

This is partially implemented in my https://github.com/lolPants/caddy-requestid module.
This is my first time writing Caddy v2 modules, so PRs to restore full v1 functionality would be appreciated 😄

[danlsgiga]

@lolPants Thank you for that... can you also provide examples of usage with the json config in your README?

Also, do you know how we could add the request_id value to the logs?

[francislavoie]

@lolPants the v1 plugin also provided a {request_id} placeholder that could be used in templates and such. I think your module should provide this as well, basically something like this (in ServeHTTP):

repl := r.Context().Value(caddy.ReplacerCtxKey).(*caddy.Replacer)

repl.Set("http.request_id", request_id)

@mholt might have an opinion on the placeholder name to use

[danlsgiga]

Yeah, agreed... having it as a placeholder is a much more elegant solution!

[francislavoie]

@danlsgiga FWIW this new plugin works just the same as the v1 did (from what I can glean from the v1 docs) aside from the placeholder not being there yet. In v1 you still needed to configure it to be written to a header to be able to use it with a placeholder later.

[lolPants]

Thanks both of you for your interest in my module! I've done a small rewrite that brings the functionality more in line with Caddy v2 concepts. It now is only responsible for setting the placeholder as suggested, what is done with that placeholder is now up to the user.

Additionally, I've also documented using it with the JSON syntax as best I can. I use Caddyfile syntax myself so I'm hoping I've got it right 😄

[francislavoie]

I love how simple it is! Thanks!

[francislavoie]

FYI it's not unlikely that it might be superseded by the tracing features in the future as @mholt said earlier, but I think the implementation as a plugin is enough to close the issue for the time being.

[lolPants]

I've also noticed since updating the module, when I rescan the repo from the Caddy Portal, it doesn't update on the website. Since the usage has changed since I first added it, this seems like something that should be addressed.

[mholt]

@lolPants Ah, so you mean this documentation is outdated? https://caddyserver.com/docs/modules/http.handlers.request_id

Hmm, I think Rescan will use @latest when it invokes the go command to download the module, maybe it is not seeing the most recent version... 🤔 I can look into it but it will have to wait for a bit, I'm tied up with something now.

You could maybe conduct an experiment, do go get ...@ whatever commit the old version is, then go get ... (with or without @latest I think is the same thing) and see if it updates to the latest commit. You could also try with and without the Go module proxy. (See Go module docs for more on that.) If it doesn't use the latest commit automatically, that could be why...