Bot Framework returns errorCode 1008 only in production deployment behind nginx reverse proxy; same code works via Dev Tunnels

Question

Adaptive card `Action.Execute` (Universal Actions for Adaptive Cards) clicks
from Microsoft Teams consistently return `errorCode 1008` / "Unable to reach
app", even though the bot responds with HTTP 200 + valid
`AdaptiveCardInvokeResponse` body in ~100–200 ms. The exact same bot binary
with the exact same Azure Bot Service registration works correctly when
exposed via Microsoft Dev Tunnels.

## Error returned to Teams

```json
{
    "errorCode": 1008,
    "message": "<BotError>Error when sending request to bot",
    "standardizedError": {
        "errorCode": 1008,
        "errorSubCode": 1,
        "errorDescription": "<BotError>Error when sending request to bot"
    }
}
HTTP 502 from  teams.microsoft.com/api/chatsvc/emea/v1/agents/{botId}/invoke

Answer 1

RESOLVED — the issue was caused by our nginx reverse proxy configuration, not the bot application itself.

We had an http-level add_header Content-Security-Policy "..." directive where the CSP value was formatted across multiple lines in the nginx config for readability purposes. nginx propagated those literal newline characters into the HTTP response header value returned to Azure Bot Service.

The bot endpoint was served over HTTP/2 (listen 443 ssl http2). Under HTTP/2 rules (RFC 9113 §10.3), CR/LF characters are not permitted inside header field values. As a result, Azure Bot Service rejected the response during HTTP/2 header parsing and returned errorCode 1008.

The issue did not reproduce when using Dev Tunnels because nginx was bypassed entirely in that setup.

Resolution: we added a location-specific add_header directive for the bot endpoint:

location ^~ /api/messages {
    add_header X-Bot-Endpoint "1" always;
    proxy_pass http://upstream;
}

In nginx, defining any add_header inside a location block disables inheritance of add_header directives from parent scopes. This prevented the malformed multi-line CSP header from being attached to bot responses, after which the Azure Bot Service communication worked correctly.

Takeaway: when reverse-proxying Bot Framework endpoints over HTTP/2, all inherited response headers should be reviewed carefully — especially CSP headers — to ensure no unintended CR/LF characters are introduced into header values.