Loading

Large HTTP Header Limitations

Udgivelsesdato: Nov 7, 2024
Løsning

SYMPTOMS

Large HTTP headers in a request or response can result in an error. Here are some examples of what may be seen.

1) You are getting HTTP 400 Bad Request or 413 Request Entity Too Large response from your application. The URL are well formed and the services are correctly called, however HTTP 400 responses are returned and there is no indication about how might be causing it in the logs. With HTTP Wire logging enabled, you will see the request in the logs, which includes a long header such as

DEBUG 2018-03-25 12:55:44,096 [[test].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.HttpMessageLogger: LISTENER
GET /test2 HTTP/1.1my-header: a3e6cc7a-b208-4b12-94a9-c66dc912b56b||...||a3cc557a-b208-4b12-94a9-c6893efa2b56b
Postman-Token: f48d9b17-87ec-4ca8-a435-48607f022232
User-Agent: PostmanRuntime/7.1.1
Accept: */*
Host: localhost:8081
accept-encoding: gzip, deflate
Connection: keep-alive


2) An API invocation through a CloudHub Shared or Dedicated Load Balancer(DLB) results in an HTTP 400 Bad request response with a text/html body including the text "400 Request Header Or Cookie Too Large". For example:

HTTP/1.1 400 Bad Request
Date: Tue, 11 Sep 2018 17:51:28 GMT
Content-Type: text/html
Content-Length: 214
Connection: close

<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
</body>
</html>


3) In the logs you will see the following stack trace for a message request that is being received.

Root Exception stack trace:
org.glassfish.grizzly.http.HttpCodecFilter: Error parsing HTTP header 
java.lang.IllegalStateException: HTTP packet header is too large 
at org.glassfish.grizzly.http.HttpCodecFilter$HeaderParsingState.checkOverflow(HttpCodecFilter.java:1968) ~[?:?] 
at org.glassfish.grizzly.http.HttpCodecFilter.decodeHttpPacketFromBuffer(HttpCodecFilter.java:978) ~[?:?] 
at org.glassfish.grizzly.http.HttpCodecFilter.decodeHttpPacket(HttpCodecFilter.java:679) ~[?:?] 
at org.glassfish.grizzly.http.HttpCodecFilter.handleRead(HttpCodecFilter.java:525) ~[?:?]

CAUSE

Including additional information within an HTTP request or response header can be rejected, if the amount is too large.
If you are deploying to Cloudhub, then both the Shared and Dedicated Load Balancers also have a limitation on the amount of data that can be handled within the request or response.
Please note that the total request size is considered by these settings and so the maximum size includes the sum of the request line as well as all HTTP headers.
 

SOLUTIONS

DEDICATED LOAD BALANCER (DLB)

From September 12, 2022, the DLB increased the request header’s size limit from 8kb to 32kb (DLB Release Notes).

To utilize the DLB's 32k, please make sure to:

  1. Update the target DLB version to the latest version
  2. Runtime: Set property mule.http.headerSectionSize up to 32k to accept the long header size (see HYBRID SERVER below)

As an example, the call flow will be:

Client send a header larger than 8k ==> DLB accepts the header ==> Runtime(CloudHub app) accepts the header by setting mule.http.headerSectionSize

However, please note that the response header size limit is still only 4k and cannot be increased.

SHARED LOAD BALANCER(SLB) / Cloudhub

There is a limit on the CloudHub Shared Load Balancer which sits between your client and your CloudHub application. This limitation is 16kb. The shared load balancer configuration is not customer configurable.

To utilize the SLB's 16k, please make sure to:

  1. Runtime: Set property 
    mule.http.headerSectionSize

    and  
    mule.http.client.headerSectionSize

    up to 16k (16384) to accept the long header size (see HYBRID SERVER below)

As an example, the call flow will be:

Client send a header larger than 8k ==> SLB accepts the header ==> Runtime(CloudHub app) accepts the header by setting mule.http.headerSectionSize


Note)
Alternatively, for both DLB and SLB, you can bypass the load balancer and hit the CloudHub worker which hosts your application directly as follows:
http://mule-worker-.cloudhub.io:8081 for an HTTP request.
 

HYBRID (ON-PREMISE) SERVER

By default, the Mule Runtime accepts only 8 KB. If you require the Mule Runtime to work with header sizes larger than this, then you can increase the sizes used by the HTTP Listener and HTTP Requester by adding the following to the <MULE_HOME>/conf/wrapper.conf

#Request Header Size
wrapper.java.additional.<n>=-Dmule.http.headerSectionSize=MAXIMUM_HEADER_SECTION_SIZE_IN_BYTES (e.g. 16384)
#Response Header Size
wrapper.java.additional.<x>=-Dmule.http.client.headerSectionSize=MAXIMUM_HEADER_SECTION_SIZE_IN_BYTES

You will need to make sure <n> and <x> are replaced with a unique integer value within the wrapper.conf

For more details, refer to the KB article How to Set Mule and Java System Properties at Startup in Various Environments

Note:

The mule.http.headerSectionSize property applies to both the HTTP Listener and HTTP Requester components:

  • For the HTTP Listener, it sets the maximum size of incoming request headers.
  • For the HTTP Requester, it sets the maximum size of outbound request headers.

The mule.http.client.headerSectionSize property applies exclusively to the HTTP Requester component. The HTTP Listener does not impose this 8 KB limit on returned headers.

Vidensartikelnummer

001121773

 
Indlæser
Salesforce Help | Article