Support Fred as a dynamic content source

[caugner]

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?

• Dev environments are not following redirects fred#811
• feat (server) Add redirects middleware in dev env fred#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.

[LeoMcA]

I approve of the aim: we should be able to use dex in development - it would allow us to remove routing logic from fred's server.

I think the approach described here is wrong in some places, e.g.

Preserve request URLs instead of applying resolveIndexHTML.

I think we should do the opposite, make the fred server capable of responding to /index.html requests. I think dex should stay as close to prod as possible, and fred should be the malleable one which mocks dex's sources as much as possible.

[caugner]

You're probably right, but note that responding to /index.html is not sufficient. Those /index.html would also need to be served from lowercased rewritten paths (e.g. _colon_).

That said, publishing @mdn/dex-cloud-server does seems to be a good first step

[LeoMcA]

Those /index.html would also need to be served from lowercased rewritten paths (e.g. colon).

Should that be handled by the rari server? It's rari which does the slugification of the jsons, right?