Support Fred as a dynamic content source

What information was incorrect, unhelpful, or incomplete?

The cloud function cannot currently use Fred's development server as SOURCE_CONTENT.

Content requests are rewritten to the static build layout (.../index.html). The content proxy also buffers responses and replaces upstream 404 responses. Fred expects the original request URL, renders its own 404 pages, and uses long-lived responses for development features such as HMR.

This prevents running the production routing middleware in front of Fred during local development.

What did you expect to see?

Add an opt-in content-source mode for HTTP application servers, for example:

SOURCE_CONTENT_MODE=server
SOURCE_CONTENT=http://localhost:3000/

In this mode, the cloud function should:

• Preserve request URLs instead of applying resolveIndexHTML.
• Stream page and asset responses from SOURCE_CONTENT.
• Preserve upstream status codes and response bodies, including 404 responses.
• Support long-lived responses without buffering them.
• Continue applying the existing redirect, locale, and origin middleware.

The current static-content behavior should remain the default and remain unchanged for deployed environments.

Do you have any supporting links, references, or citations?

• https://github.com/mdn/fred/issues/811
• https://github.com/mdn/fred/pull/812

Do you have anything more you want to share?

Generating or remotely loading canonicals.json and redirects.json, publishing the cloud server, and orchestrating the Fred and Rari processes are outside the scope of this issue.

Start at the cloud function's content proxy and the resolveIndexHTML path, then trace how SOURCE_CONTENT requests pass through the existing redirect, locale, and origin middleware. The server mode is complete when request URLs, response bodies, status codes, and long-lived responses are preserved, while static behavior remains the default and unchanged.