pmx-cork-dispatch

The HTTP server of the pmx-cork suite, the libpve-http-server-perl analog, built on pmx-cork-tasks and pmx-cork-sdk. Each module reimplements a named construct of the Proxmox Perl stack, and the package boundary follows the Proxmox package map so the two stay easy to compare after a PVE upgrade.

Module	Mirrors
engine	PVE::APIServer::AnyEvent: the shared Starlette application builder with the auth gate middleware, the public-lane exemptions, gzip and ETag static serving and error rendering
dispatch	PVE::HTTPServer::rest_handler: the request pipeline, collect, validate, RBAC, proxyto, forward to the daemon, execute
responses	PVE::APIServer::Formatter: the Proxmox JSON envelope and the structured audit record
proxy_request	the proxy-to-daemon bridge over the daemon's Unix socket for protected routes
crossnode	proxyto forwarding to another cluster node, and relaying a route this node does not have to the node that does. The peer is whatever the auth backend says to trust; today that is the SHA-256 of the leaf it serves

Why dispatch can live here

In PVE, rest_handler lives in pve-manager, because it hardwires PVE::RPCEnvironment and so cannot sit in the generic server package. Here the pipeline is handed the auth object at assembly time (the runtime resolves it from runtime.conf by name), so the whole pipeline sits in the generic layer while the identity and RBAC backend stays replaceable.

The {node} in a permission path

The pipeline fills {node} in a route's permission path with the node that will execute the request: the proxyto target, or the local node. A route without proxyto whose permission path names {node} cannot be scoped this way and is refused with a 500 that says so. Such a route checks its target node inside the handler.

Layering

Imports pmx_cork_tasks and pmx_cork_sdk, never pmx_cork_host; a test pins that. The concrete ProxyService and DaemonService definitions live in the runtime, as PVE::Service::pveproxy and pvedaemon ship with pve-manager rather than with the server library. The runtime assembles these parts into the running services and owns the systemd units; this package is the engine, not the deployment.

Ships as python3-pmx-cork-dispatch.