Skip to content

Feature Request: Add support for HTTP_HOST in HTTP/3 requests (RFC 9114 compliance) - JUST Implemented in ANGIE #912

@MarcoMarcoaldi

Description

@MarcoMarcoaldi

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_host is widely used in rewrite rules, logging, and conditional logic.
  • Without this fix, configurations that depend on $http_host fail 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_host behaves 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions