One service serves one publisher, because the settings are read at one key before a request is looked at #1270

The problem

A Fastly service reads one application config blob, at the key its __KEY selector names. An operator running the server for several publishers runs a service for each, with its own domains, stores, deploys and rollbacks, although the code is the same and only the settings differ. Two things stand in the way of one service reading a blob for each host. The key is settled for the service before a request is looked at, and a sandbox that serves several requests keeps the one application it built first, so the second publisher's request would be answered with the first publisher's application.

The change

A __KEY selector that contains {host} names a blob for each host. The entry point puts the request's host, lower case and without a port or a trailing dot, in the placeholder's place before anything reads settings, so the probes, the application build and the finalizers all read the blob of the publisher the request is for. A host with no blob, or a Host that is not a host name, is answered 421 Misdirected Request and never from a shared blob. /health answers before any config is read. A selector without the placeholder is the key as it stands, so a service that reads one blob is unchanged.

The placeholder goes in the selector that already exists because a staged deploy copies every runtime entry of a service and replaces only the config key selectors. A switch of its own would be copied with the rest, and a staged version would then choose by host and read production blobs. The reusable sandbox keeps each application under the key of the blob it was built from, the eight most recently served, and finds one by that key alone. Every process-wide static in core, the modules and the Fastly adapter was read for this change, and none holds anything read from settings.

The publishers on one service share the secret store, the request signing keys and the sandbox's memory bound.

Where it is

Draft on the fork, jwrosewell#6, on top of page changes as middleware (fork pull request 5). A harness under Viceroy pushes a blob for each of two hosts and shows each host answered from its own origin, and 32 deliberate faults were each caught by a test or by the harness. Left for later are a staged deploy by host, which is a change to EdgeZero's Fastly tool, the same on the other adapters, and one blob for a publisher with several names.