Track host support for trusted forwarded management URL origins

[andystaples]

Summary

Track the Durable Functions extension change required before azure-functions-durable 2.x can safely honor Forwarded and X-Forwarded-* headers when constructing HTTP management payload URLs.

Background

PR #237 adds canonical HTTP management URL construction for #233. Forwarded origins must remain disabled by default because adopting request headers without the host's extensions.durableTask.httpSettings.useForwardedHost opt-in can disclose the management system key through an attacker-controlled Location host.

The current Durable extension middleware-passthrough binding serializes httpBaseUrl, maximum gRPC message size, and timeout, but does not serialize useForwardedHost. As a result, Python cannot distinguish a trusted proxy configuration from an untrusted request. The extension change may take months to release and become broadly available.

Required host work

• Serialize the effective HttpOptions.UseForwardedHost value in the middleware-passthrough durable-client binding payload.
• Add a host test that verifies the exact emitted JSON for both the default-off and enabled configurations.
• Release the change through the extension and applicable extension bundles.
• Enable Python support only when the host-provided opt-in is available, without changing the secure default for older hosts.

Related work

• Use canonical management URL construction for HTTP payloads #233
• PR Use canonical management URLs for HTTP payloads #237

[andystaples]

@berndverst @andystaples The remaining choices for PR #237 are:

1. Keep the optional useForwardedHost parsing in the Python client, defaulting to false. This is secure for current hosts and leaves the client ready, but the forwarded-header path remains dormant until the host change is released and broadly deployed.
2. Remove forwarded-header adoption from PR Use canonical management URLs for HTTP payloads #237 and defer that part of Use canonical management URL construction for HTTP payloads #233 entirely to this tracking issue. This avoids carrying a host contract that no released extension can emit, but proxy-origin parity remains unavailable until a later Python release.

The host-independent parts of #237—canonical httpBaseUrl paths, template preservation, encoded instance IDs, and rewindPostUri—can ship under either option. I have left the reopened review thread unresolved pending this decision.

[andystaples]

Closing as superseded by the upstream Durable extension tracking issue: Azure/azure-functions-durable-extension#3503.