[
https://issues.apache.org/jira/browse/CAMEL-26090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26090 started by shashank.
----------------------------------------
> camel-hl7 - add a maxFrameLength option to the HL7 MLLP Netty decoder
> ---------------------------------------------------------------------
>
> Key: CAMEL-26090
> URL: https://issues.apache.org/jira/browse/CAMEL-26090
> Project: Camel
> Issue Type: Improvement
> Components: camel-hl7
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> The Netty decoder of camel-hl7, {{HL7MLLPNettyDecoder}} (made by
> {{HL7MLLPNettyDecoderFactory}}), is a Netty {{DelimiterBasedFrameDecoder}}
> whose maximum frame length is the constant {{Integer.MAX_VALUE}} (main
> ed3d719b379c, {{HL7MLLPNettyDecoder.MAX_FRAME_LENGTH}}). There is no option
> to set a smaller one, so the decoder keeps every byte a peer sends until the
> two end bytes arrive, however long the message gets. The camel-netty
> {{textline}} codec has {{decoderMaxLineLength}} for this, and camel-mllp has
> {{maxBufferSize}}; the HL7 Netty decoder has nothing comparable.
> *Proposal*: a {{maxFrameLength}} option on {{HL7MLLPNettyDecoderFactory}}
> (stored in {{HL7MLLPConfig}}), passed to the {{DelimiterBasedFrameDecoder}}
> instead of the constant. Default {{Integer.MAX_VALUE}}, so nothing changes
> for existing routes; 0 and negative values are refused with an
> {{IllegalArgumentException}}. Netty's rule applies: the length is counted
> from the start of the data up to the end bytes (start byte included, end
> bytes not), a message of exactly the limit is decoded, and as soon as more
> bytes than the limit have arrived without the end bytes the decoder throws a
> {{TooLongFrameException}} and discards the data up to the next end bytes. A
> netty consumer passes the exception to its exception handler and closes the
> connection. The name follows Netty and camel-netty's
> {{ChannelHandlerFactories.newDelimiterBasedFrameDecoder(maxFrameLength,
> ...)}}. The Mina codec ({{HL7MLLPCodec}}) and the encoder are not changed.
> Documented in the HL7 MLLP codec table of hl7-dataformat.adoc, including that
> a message of exactly the limit fails when its first end byte arrives in a
> read of its own, so the limit needs some margin.
> *Tests*: a decoder test on an {{EmbeddedChannel}} (at the limit, one byte
> over, data without end bytes and the next message, the factory, the default,
> invalid values) and a route test with a {{netty:tcp}} consumer: a connection
> that sends 2000 bytes without end bytes to a listener with a limit of 1024 is
> closed, the exception handler gets the {{TooLongFrameException}}, and a
> normal request on a new connection is answered. With the decoder passing
> {{Integer.MAX_VALUE}} as on main, 4 of the 7 tests fail. camel-hl7 with the
> change: 79 tests, 0 failures.
> *Affected*: the same constant is on main, camel-4.23.x, camel-4.22.x,
> camel-4.18.x and camel-4.14.x (read, not run). A new option, for main.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
