Azure Application Gateway HTTP2 ERR_CONNECTION_CLOSED

Jan Baggen 0 Reputation points
2025-04-11T15:13:13.75+00:00

With Application Gateway WAF V2 we see ERR_CONNECTION_CLOSED with requests for chunk-.js files. If we disable HTTP2 the request got handled with HTTP1.1 without problems. There's a clear pattern of requests for Javascript "chunk" files (named like chunk-*.js) failing with the error net::ERR_CONNECTION_CLOSED. Only Javascript "chunk" request fail. when the browser retries the same request the request is completed correctly.

t=72999 [st= 177]       -HTTP_TRANSACTION_SEND_REQUEST
t=72999 [st= 177]       +HTTP_TRANSACTION_READ_HEADERS  [dt=771]
t=73770 [st= 948]          HTTP2_STREAM_ERROR
                           --> description = "Abandoned."
                           --> net_error = "ERR_CONNECTION_CLOSED"
                           --> stream_id = 1247
t=73770 [st= 948]          HTTP_TRANSACTION_RESTART_AFTER_ERROR
Azure Application Gateway
Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,213 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Akila G 0 Reputation points Microsoft Employee
    2025-04-16T10:33:21.7033333+00:00

    Hello @Jan Baggen Thanks for reaching Microsoft Q&A, I'm @Akila G from Azure Networking POD Team,

    Issue - When using Application Gateway WAF V2 with HTTP/2 enabled, requests for JavaScript "chunk-*.js" files intermittently fail with net::ERR_CONNECTION_CLOSED. Disabling HTTP/2 resolves the issue, allowing the requests to succeed via HTTP/1.1. The problem is isolated to chunked JavaScript files, and retrying the failed requests usually works.

    Solution - Header Size Limitations and Request Failures in HTTP/2

    In certain scenarios, especially within enterprise environments, the size of HTTP request headers can grow significantly due to factors such as increased user group memberships and the use of large cookies for session management.

    When the total size of the HTTP headers exceeds the server's configured limits, the request may be rejected, resulting in error responses such as HTTP 400 (Bad Request) or HTTP 431 (Request Header Fields Too Large).

    This issue is particularly relevant in HTTP/2, which enforces a default maximum header size limit of 16 KB (16,384 bytes). A common contributor to exceeding this limit is an excessively large Cookie header, often caused by:

    • Multiple cookies with large values (e.g., encoded JWT tokens),

    • Applications storing too much user or session data in cookies,

    • Users being assigned to a high number of security groups, which can inflate token or header size when identity information is included in requests.

    To prevent these errors, it's important to:

    • Optimize the use of cookies by storing only essential data,

    • Consider server-side session storage to minimize header bloat,

    • Reduce the number or size of headers sent with each request,

    • Or, where appropriate and secure, increase the server’s header size limit.

    By addressing these factors, organizations can ensure better reliability and performance in applications operating over HTTP/2.

    Please click Accept Answer and upvote if the above was helpful.

    Thanks.

    @Akila G


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.