[IDEA] Add Request Header Size on HTTP Listener

[gabrielestenico]

Add Request Header Size on HTTP Listener as it was done on BridgeLink: Innovar-Healthcare/BridgeLink#129

[pacmano1]

What's actually failing here? 8k is already a big header. Need the error and the header size you're hitting before we add a knob for it.

[gabrielestenico]

In the Italian National Electronic Health Record (FSE) integration, we have a real use case where the HTTP request contains two JWT tokens:

• Authorization: Bearer <JWT>
• FSE-JWT-Signature: <JWT>

The second JWT contains a large amount of metadata, so together the two headers easily exceed 8 KB.

Example:

curl -X POST \
  'https://<HOST>:<PORT>/v1/documents/validation' \
  -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c...' \
  -H 'FSE-JWT-Signature: eyJdWIiOiIxMjM0NTY3ODkw...' \
  -H 'accept: application/json' \
  -H 'Content-Type: multipart/form-data' \
  -F 'requestBody={
    "healthDataFormat":"CDA",
    "mode":"ATTACHMENT",
    "activity":"VALIDATION"
  }' \
  -F 'file=@CDA_OK.pdf;type=application/pdf'

Initially, we generated the JWTs in an external application and forwarded the request to Mirth through a proxy channel. The proxy then called the national gateway.

However, because of this header size limitation, we eventually had to move the JWT generation directly into Mirth. Otherwise, the proxy approach was not viable.

To reproduce the issue, I created a simple HTTP Listener channel that expects these two headers and forwards the request to another channel.

The request never reaches the second channel. Instead, the first channel immediately returns:

<h1>Bad Message 431</h1>
<pre>reason: Request Header Fields Too Large</pre>

This seems to indicate that the request is rejected by the embedded HTTP server before Mirth has a chance to process it.

For integrations that require large authentication headers (such as the Italian EHR APIs), it would be very useful to make the maximum accepted request header size configurable.

[NicoPiel]

Sounds like a good use-case to me.

[pacmano1]

Nice write up @gabrielestenico . I think I will take a look at this in a day or two.