Application Gateway RFC9112 implementation, reject multi host header requests

Application Gateway already treats malformed or non‑RFC-compliant requests as client errors and returns 4xx responses, including 400 for bad requests. The announced change is a tightening of RFC compliance specifically for multiple Host headers.

From the available information, the following points are relevant for validation and impact assessment:

1. Application Gateway relies on the HTTP/1.1 Host header for routing
   • Multi-site hosting on a single public IP and port is based on the HTTP/1.1 Host header and, for TLS, SNI.
   • Because routing depends on a single Host header, multiple Host headers are inherently nonstandard and not required for normal operation.
   • Application Gateway can’t delete the Host header via header rewrite rules, which ensures that a valid Host header is always present for routing.
2. 400 responses are already used for malformed/non‑RFC requests
   • Application Gateway returns HTTP 400 when the request is not compliant with RFC, including malformed headers and invalid Host values.
   • Examples of non‑compliant requests that already result in 400 include:
     • Invalid Host in request line (for example, host containing two colons).
     • Missing Host header.
     • Malformed characters in the request.
     • Invalid HTTP version or method.
     • Duplicate headers.
   • The new behavior (rejecting multiple Host headers) is consistent with this existing pattern of rejecting malformed or ambiguous Host information.
3. How to validate impact with current tooling
   • Application Gateway metrics and diagnostic logs already capture 4xx/5xx distributions and detailed request information (URI, client IP, response code).
   • To assess impact:
     1. Enable and review Application Gateway diagnostic logs if not already enabled, focusing on 400 responses.
     2. Use the existing logs to identify patterns of 400 responses that might be related to malformed Host headers or duplicate headers.
     3. Correlate requests using X-appgw-trace-id (presented to the backend and logged via the transactionId field in diagnostic logs) to trace problematic requests end-to-end.
   • Because the Host header cannot be deleted by rewrite rules, and Application Gateway preserves or overrides the Host in a controlled way, any client sending multiple Host headers would already be considered nonstandard and likely visible as 4xx/400 patterns in logs.
4. Why the change is unlikely to affect normal clients
   • Normal HTTP/1.1 clients send exactly one Host header; multiple Host headers are non‑compliant with the HTTP specification.
   • Application Gateway’s design assumes a single Host header for:
     • Multi-site routing on a single IP/port.
     • TLS SNI-based routing.
   • Existing guidance emphasizes preserving or cleanly overriding a single Host header between reverse proxies and backends; there is no supported scenario that depends on multiple Host headers.

Given the available data, the practical validation path is:

1. Ensure Application Gateway diagnostic logging is enabled.
2. Analyze recent 400 responses to detect any systematic pattern that could indicate malformed Host usage or duplicate headers.
3. Confirm that no upstream component (CDN, custom proxy, firewall) is intentionally injecting multiple Host headers; such behavior would already be non‑RFC-compliant and should be corrected.

If no abnormal 400 patterns or upstream header manipulations are found, the environment is effectively operating with single Host headers today, and the enforcement on 15 April 2026 should not introduce new impact.

References:

• Application Gateway multi-site hosting
• HTTP response codes in Application Gateway
• Rewrite HTTP headers and URL with Application Gateway
• How an application gateway works
• Preserve the original HTTP host name between a reverse proxy and its back-end web application