[awf] api-proxy: BYOK Azure OpenAI routing fails with 404 or 401 across base URL variants

[lpcox]

Problem

When users configure BYOK with Azure OpenAI via COPILOT_PROVIDER_BASE_URL, the AWF api-proxy sidecar fails to route requests correctly, returning HTTP 404 or 401 regardless of base URL format tried.

Context

Upstream report: github/gh-aw#35483

Root Cause

The api-proxy Copilot adapter (containers/api-proxy/) likely does not handle Azure OpenAI's deployment-based URL structure (/openai/deployments/{deployment}/...) or the api-key header that Azure requires (instead of Authorization: Bearer). Azure OpenAI uses a distinct auth header and URL path format incompatible with the standard OpenAI adapter.

Proposed Solution

1. In containers/api-proxy/, add an Azure OpenAI adapter that detects Azure endpoints (e.g., *.openai.azure.com) and rewrites requests to use api-key: <key> header instead of Authorization: Bearer.
2. Accept COPILOT_PROVIDER_BASE_URL values in the canonical Azure format and normalize the deployment path.
3. Add integration test with a mock Azure OpenAI endpoint to verify 200 responses across all supported URL variants.

Generated by Firewall Issue Dispatcher · sonnet46 1.2M · ◷

[github-actions]

👋 Hello! I noticed this issue might be related to existing issues:

• api-proxy: middle_power modelFallback rewrites Azure OpenAI deployment names to base-catalog names, causing HTTP 404 DeploymentNotFound on BYOK targets #3975 — api-proxy: middle_power modelFallback rewrites Azure OpenAI deployment names to base-catalog names, causing HTTP 404 DeploymentNotFound on BYOK targets (open) — Both issues describe BYOK Azure OpenAI requests returning HTTP 404 through the api-proxy, with the root cause traced to the proxy mishandling Azure deployment identifiers.
• [awf] Azure OpenAI BYOK: three compounding failures prevent Azure-hosted model usage #3239 — [awf] Azure OpenAI BYOK: three compounding failures prevent Azure-hosted model usage (closed/completed) — This closed issue covers the same scenario: COPILOT_PROVIDER_BASE_URL pointing to Azure OpenAI, the api-proxy not recognizing Azure-specific configuration, and requests failing with 404. It may have been partially addressed.

If either of these covers your concern, you may want to reference them or reopen #3239 if the fix was incomplete. Otherwise, feel free to clarify how this issue differs (e.g., the specific focus on the api-key auth header vs. Authorization: Bearer)!

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #4018 · sonnet46 673.4K · ◷

[zarenner]

@lpcox FYI I don't think (1) in the proposed solution is necessary.

I just confirmed that with:

• https://<resource>.openai.azure.com/openai/v1/chat/completions (with model in body set to the deployment name)
• https://<resource>.openai.azure.com/openai/deployments/<model_deployment_name>/chat/completions?api-version=2024-06-01

Both work just fine with Authorization: Bearer <foundry-api-key> or api-key: <foundry-api-key> header. I have not tested with Entra auth to know if the reverse is true.

edit: When using Entra access tokens, ONLY Authorization: Bearer ... works.