4 ms·

So it's mod_php for Caddy, in reverse? The traditional idea is to build a plug-in for the parent webserver. By essentially "making a fork" of Caddy, if you wan

So it's mod_php for Caddy, in reverse? The traditional idea is to build a plug-in for the parent webserver. By essentially "making a fork" of Caddy, if you want to add other plugins to Caddy and then incorporate them into FrankenPHP, it's a lot more work. If instead you ship a PHP plugin to Caddy, you can manage Caddy instead and mix and match different functionality in one place. But I guess it's heretical to suggest somebody use plugins in Go, if the whole idea is everything is a static binary.

mike_d 4y ago
Early Hints breaks a lot of the common APIs (like FastCGI/FPM) where you are expected to have one request and one response. I don't know how Caddy specifically works, but I suspect that may be the reason for the fork.
- mholt 4y ago
  Early Hints support was added to Caddy's proxy by Kevin Dunglas, the author of FrankenPHP. No fork required for Early Hints!
mholt 4y ago
I don't think this forks Caddy. Rather, it is a Caddy plugin: https://github.com/dunglas/frankenphp/blob/main/caddy/caddy.go https://github.com/dunglas/frankenphp/blob/main/caddy/caddy.... It uses mainline Caddy: https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod
- deleted 4y ago
  [deleted]
- 0xbadcafebee 4y ago
  Can I use an officially released build of Caddy and have that official Caddy executable load FrankenPHP?
  - kdunglas 4y ago
    Definitely! (using xcaddy and compiling PHP yourself, for now)
  - mcpherrinm 4y ago
    Caddy plug-ins are statically compiled into the server. Generally you need to build your own binaries if you’re using plugins. There’s an official script, xcaddy, to make that easy.
    - mekster 4y ago
      Hard to think this method takes off as people are reluctant to run their own binary that can't be updated with the rest of the system which in turn gives less users to report bugs and blogs about usage/reviews.
      - ratorx 4y ago
        Depends on the package manager. Some package managers support overlays so you can keep your package modifications as a layer on top of the base package. I know you can using Nix for sure. I think Arch/pacman (Arch Build System) and Gentoo/portage (since it is source-based) also have this concept, but I’ve never used it. No clue about other package managers. The downside is that package updates will require a recompilation, but you can use binary caches to centralise this slightly.
tomcam 4y ago
I love the idea but as far as I can tell there isn’t a portable way to do plug-ins in go that works with windows, is there?
- francislavoie 4y ago
  If you're talking about Caddy, its plugins are cross-platform, because Go (as long as you don't use CGO, or at least that your plugin that needs CGO also works on Windows). Read about Caddy's architecture here: https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture
chrsig 4y ago
go does have some support for dynamically loaded shared libraries. I haven't used it, so I can't speak to how good it is, or any pitfalls. https://pkg.go.dev/plugin https://pkg.go.dev/plugin
- philosopher1234 4y ago
  It is not good. I don’t know of any major projects that use it. Instead people: * compile in plugins * run plugins as separate processes and expect them to implement a specific RPC api Compiling in plugins is more practical in Go then it might be in another language, due to the regularity of the go build system.

mike_d 4y ago

Early Hints breaks a lot of the common APIs (like FastCGI/FPM) where you are expected to have one request and one response. I don't know how Caddy specifically works, but I suspect that may be the reason for the fork.

mholt 4y ago
Early Hints support was added to Caddy's proxy by Kevin Dunglas, the author of FrankenPHP. No fork required for Early Hints!

mholt 4y ago

I don't think this forks Caddy. Rather, it is a Caddy plugin: https://github.com/dunglas/frankenphp/blob/main/caddy/caddy.go https://github.com/dunglas/frankenphp/blob/main/caddy/caddy.... It uses mainline Caddy: https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod

deleted 4y ago
[deleted]
0xbadcafebee 4y ago
Can I use an officially released build of Caddy and have that official Caddy executable load FrankenPHP?
- kdunglas 4y ago
  Definitely! (using xcaddy and compiling PHP yourself, for now)
- mcpherrinm 4y ago
  Caddy plug-ins are statically compiled into the server. Generally you need to build your own binaries if you’re using plugins. There’s an official script, xcaddy, to make that easy.
  - mekster 4y ago
    Hard to think this method takes off as people are reluctant to run their own binary that can't be updated with the rest of the system which in turn gives less users to report bugs and blogs about usage/reviews.
    - ratorx 4y ago
      Depends on the package manager. Some package managers support overlays so you can keep your package modifications as a layer on top of the base package. I know you can using Nix for sure. I think Arch/pacman (Arch Build System) and Gentoo/portage (since it is source-based) also have this concept, but I’ve never used it. No clue about other package managers. The downside is that package updates will require a recompilation, but you can use binary caches to centralise this slightly.

tomcam 4y ago

I love the idea but as far as I can tell there isn’t a portable way to do plug-ins in go that works with windows, is there?

francislavoie 4y ago
If you're talking about Caddy, its plugins are cross-platform, because Go (as long as you don't use CGO, or at least that your plugin that needs CGO also works on Windows). Read about Caddy's architecture here: https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture

chrsig 4y ago

go does have some support for dynamically loaded shared libraries. I haven't used it, so I can't speak to how good it is, or any pitfalls. https://pkg.go.dev/plugin https://pkg.go.dev/plugin

philosopher1234 4y ago
It is not good. I don’t know of any major projects that use it. Instead people: * compile in plugins * run plugins as separate processes and expect them to implement a specific RPC api Compiling in plugins is more practical in Go then it might be in another language, due to the regularity of the go build system.