-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Description
Feature Request: Add support for HTTP_HOST in HTTP/3 requests (RFC 9114 compliance)
Description
Currently, when handling HTTP/3 (QUIC) requests, NGINX does not properly set the $http_host variable.
This is inconsistent with how NGINX handles HTTP/1.1 and HTTP/2 requests, and it breaks compatibility with many server configurations, rewrites, and application logic that rely on $http_host.
According to RFC 9114 (HTTP/3), Section 4.2 ("Request Pseudo-Header Fields"):
"If the :scheme pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an :authority pseudo-header field or a Host header field. If these fields are present, they MUST NOT be empty. If both fields are present, they MUST contain the same value."
Effectively, the :authority field in HTTP/3 has the same role as the Host header in HTTP/1.1.
NGINX should map the HTTP/3 :authority pseudo-header field to the $http_host variable, ensuring behavior consistent across HTTP/1.1, HTTP/2, and HTTP/3. This would eliminate configuration issues and application breakages when moving to HTTP/3.
Considerations
$http_hostis widely used in rewrite rules, logging, and conditional logic.- Without this fix, configurations that depend on
$http_hostfail under HTTP/3. - Correct mapping would align NGINX with the requirements of RFC 9114 and prevent unexpected regressions for users adopting HTTP/3.
- This is a backward-compatible change since it only ensures that
$http_hostbehaves the same way as in HTTP/1.1 and HTTP/2.
Reference implementation
The web server ANGIE has already addressed this issue by correctly mapping the HTTP/3 :authority pseudo-header to the equivalent $http_host variable.
See: ANGIE commit implementing the fix.
Request
Please consider adding support for $http_host in HTTP/3, mapping it from the :authority pseudo-header field as per RFC 9114.
This would improve compatibility, ensure consistency across HTTP versions, and remove a significant adoption barrier for HTTP/3 in production environments.