Azure Application with WAF SKU return error 500 after WAF is enabled

Question

My application is hosted behind Azure Application Gateway WAF and uses a legacy Thai character encoding (Windows-874) in query string parameters. The application has been working successfully since the beginning of the app gateway provisioning and the issue was first observed around 8 June 2026 where the application gateway return Error code 500 with "Internal Service Error

Symptoms

• Requests containing Thai text in the Arguments query string parameter fail when Azure WAF is enabled.
• The same requests succeed when WAF is disabled.
• WAF is configured in Detection Mode (not Prevention Mode).
• Firewall logs show only detection events ("Pattern match") and do not show blocking actions.
• The application uses charset="Windows-874" and query string values contain Windows-874 encoded Thai characters (for example %CA, %BA, %C3, %D4) rather than UTF-8 encoded characters.

Additional Findings

• Application Gateway Firewall Logs show only pattern match detection events and no WAF block actions.
• No corresponding request can be found in IIS logs during failure scenarios.
• The backend pool and HTTP setting are successfully selected, but no backend response information is recorded.
• The issue appears only when requests contain Windows-874 encoded Thai characters.

What could potentially be the issue?

Answer 1

Hi Sawachol Rojanaporn,

Welcome to Microsoft Q&A Platform.

As discussed, the issue appears to be related to the request encoding format. Azure Application Gateway WAF performs URL decoding using standard RFC 3986 percent-encoding and supports ASCII and UTF-8 encoded values during request inspection.

The affected requests contain Thai characters encoded using Windows-874 (for example: %CA, %BA, %C3, %D4). These byte sequences are valid in Windows-874 but are not UTF-8 encoded values.

Since:

• Requests encoded in Windows-874 result in HTTP 500 when WAF is enabled.
• The same requests encoded in UTF-8 succeed successfully.
• No WAF block actions are observed.

This indicates the behavior is related to how the Windows-874 encoded query string is processed during WAF URL decoding/normalization before the request is forwarded to the backend.

As a long-term recommendation, we suggest updating the application to use UTF-8 encoding for query string parameters, as UTF-8 encoded requests are processed successfully through Application Gateway WAF.

Pleaseand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

Answer 2

The most likely cause is that Azure Application Gateway WAF is treating the Windows‑874–encoded Thai characters in the query string as invalid or malformed HTTP headers/fields, which leads Application Gateway itself to fail the request with a 5xx error before it ever reaches the backend.

From the Application Gateway logging perspective, similar issues are surfaced as ERRORINFO_INVALID_HEADER or related 5XX error info entries, where:

• Application Gateway detects an invalid or partially invalid header or request component and
• Returns a 5xx (often 500/502) to the client
• The backend never sees the request, so nothing appears in IIS logs

This matches the described behavior:

• WAF is only in Detection mode, so it does not actively block at the WAF rule level.
• Firewall logs show only pattern matches (no explicit block), but the gateway still returns 500.
• No backend (IIS) logs are generated for failing requests, indicating the failure happens inside Application Gateway.
• The problem is specific to non‑UTF‑8, legacy encoding in the query string.

In such cases, the gateway’s HTTP parser can treat certain byte sequences (especially when not UTF‑8 and when combined with %-encoded values) as invalid characters in headers or request lines, which triggers internal error handling and a 5xx response.

To confirm and further troubleshoot, check:

1. Application Gateway resource logs for 5XX error info entries such as:
   • ERRORINFO_INVALID_HEADER (invalid header / characters)
   • Other ERRORINFO_* 5XX entries that indicate parsing or upstream issues
2. Backend health and probe status to verify that the backend is otherwise healthy and reachable.

If ERRORINFO_INVALID_HEADER or similar appears, the documented guidance is to ensure the client request does not contain disallowed characters (CR, LF, NULL, or similar control characters) and to normalize or change encoding so that headers and query strings conform to what Application Gateway expects.

Because the issue started recently and is tied to specific encoded characters, it is likely related to stricter parsing/validation behavior in the gateway/WAF pipeline, which now rejects or mishandles those Windows‑874 sequences.

---

References:

• HTTP response codes in Application Gateway
• Azure Application Gateway monitoring data reference
• Troubleshoot Web Application Firewall (WAF) for Azure Application Gateway
• Troubleshoot backend health issues in Application Gateway