Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Honor forwarded headers when creating management URLs

Offen
  • Stimmt etwas nicht?
#618 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
62/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
azure, python
Bereich
api, backend

Rechercherichtung

Beginne in azure/durable_functions/models/DurableOrchestrationClient.py damit, get_client_response_links() und _replace_url_origin() zu lesen. Verwende die Reproduktion auf Quellcodeebene aus dem Issue, um nachzuverfolgen, wie request.url den Ursprung der Management-URL ersetzt, und untersuche anschließend das erwartete Opt-in-Verhalten für weitergeleitete Header. Fertig ist es, wenn vertrauenswürdige Forwarded- oder X-Forwarded-Header das clientseitige Schema und den Host liefern, während das Standardverhalten unverändert bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Enhancement fixed-in-v2 P3

🐛 Describe the bug

A clear and concise description of what the bug is.

DurableOrchestrationClient.create_check_status_response() and get_client_response_links() do not consider Forwarded, X-Forwarded-Host, or X-Forwarded-Proto when constructing management URLs.

The SDK copies the extension-provided management URL templates, then unconditionally replaces their origin with the scheme and authority from request.url. Behind Azure Front Door, Application Gateway, or another reverse proxy, request.url can contain the internal origin. The resulting Location, statusQueryGetUri, and other management URLs can therefore expose an internal hostname or use HTTP even when forwarded headers describe the public HTTPS origin.

The Durable Functions extension added opt-in forwarded-header support in Azure/azure-functions-durable-extension#3083. Out-of-process binding templates are generated without an HTTP request, however, and the Python SDK subsequently replaces their origin from request.url, so that extension behavior does not cover this Python path.

This is separate from #355: current Azure Linux managed hosting correctly returns HTTPS management URLs for ordinary HTTPS-only Function Apps.

🤔 Expected behavior

What should have happened?

When trusted forwarded-header handling is enabled, Python-generated management URLs should use the client-facing scheme and host from Forwarded or X-Forwarded-Proto/X-Forwarded-Host, consistent with the Durable Functions extension behavior. Without opt-in, existing request.url behavior should remain unchanged.

☕ Steps to reproduce

What Durable Functions patterns are you using, if any?
Any minimal reproducer we can use?
Are you running this locally or on Azure?

  1. Run a Python Durable Functions HTTP starter behind a reverse proxy.
  2. Have the proxy forward a public HTTPS origin using X-Forwarded-Proto: https and X-Forwarded-Host: public.example.com, while the worker receives an internal request.url such as http://internal.example/api/start.
  3. Return client.create_check_status_response(req, instance_id).
  4. Observe that the management URL origins use http://internal.example rather than https://public.example.com.

A source-level reproduction is also sufficient: initialize the client with an HTTPS management URL template, call get_client_response_links() with an HTTP request.url, and observe that _replace_url_origin() downgrades the template to HTTP.

Relevant implementation: azure/durable_functions/models/DurableOrchestrationClient.py, in get_client_response_links() and _replace_url_origin().

⚡If deployed to Azure

We have access to a lot of telemetry that can help with investigations. Please provide as much of the following information as you can to help us investigate!

  • Timeframe issue observed: N/A; identified through source analysis of reverse-proxy behavior
  • Function App name: N/A
  • Function name(s): N/A
  • Azure region: N/A
  • Orchestration instance ID(s): N/A
  • Azure storage account name: N/A

If you don't want to share your Function App or storage account name GitHub, please at least share the orchestration instance ID. Otherwise it's extremely difficult to look up information.

Vorherrschende Sprache
Python
Sterne
157
Forks
71
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Azure/azure-functions-durable-python

Alle Issues in Azure/azure-functions-durable-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.