[
https://issues.apache.org/jira/browse/CAMEL-25318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-25318:
-----------------------------------
Assignee: shashank
> camel-smpp - an 8-bit message is split by its length in characters, not
> bytes, and a message one segment past 255 gets the segment count 0
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25318
> URL: https://issues.apache.org/jira/browse/CAMEL-25318
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> *1. Split decision.* {{SmppSmCommand.splitBody}} sends the bytes of
> {{getShortMessage(message)}} (for an 8-bit alphabet the body as {{byte[]}}),
> but {{createSplitter}} creates the 8-bit splitter with
> {{message.getBody(String.class).length()}}. An 8-bit short message holds 140
> octets, and the splitter compares that length with 140. When the bytes decode
> (exchange charset, UTF-8 by default) to fewer characters than there are
> bytes, the message is not split and one short message of more than 140 octets
> is sent: non-ASCII text with an 8-bit alphabet, or binary data that contains
> valid UTF-8 sequences (for example 150 bytes that decode to 50 characters).
> This needs the 8-bit alphabet in the {{CamelSmppAlphabet}} or
> {{CamelSmppDataCoding}} header (the body is then sent as {{byte[]}}), or an
> 8-bit alphabet on the endpoint together with a multi-byte {{encoding}} such
> as UTF-8; with the 8-bit alphabet on the endpoint and the default
> {{encoding}} ISO-8859-1, characters and bytes agree.
> *2. Segment count.* {{SmppSplitter.split}} applies the limit of 255 segments
> before it counts the last partial segment:
> {code:java}
> int segmentNum = message.length / segmentLength;
> if (segmentNum > MAX_SEG_COUNT) { segmentNum = MAX_SEG_COUNT; messageLength =
> segmentNum * segmentLength; }
> if ((messageLength % segmentLength) > 0) { segmentNum++; }
> {code}
> A message of 255 full segments and a few more bytes is split into 256
> segments, and {{(byte) 256}} = 0 is written as the total in every UDH; longer
> messages are truncated to 255 segments as intended. With the fix such a
> message is truncated to 255 segments too (with the default {{ALLOW}} policy
> the bytes after the 255th segment are dropped, as for every longer message
> today).
> h3. Reproduction
> New {{SmppSplitBodyTest}} ({{splitBody}} of {{SmppSubmitSmCommand}}): 150
> bytes of binary data and 100 characters of {{é}} (200 bytes) with
> {{ALPHA_8_BIT}} come back as one segment ({{expected: <2> but was: <1>}}),
> and 255 * 134 + 1 bytes as 256 segments ({{expected: <255> but was: <256>}});
> 140 bytes unsplit is the control. Two runs on main.
> h3. Proposed fix
> Create the 8-bit splitter with the length of the encoded message; count the
> partial segment before applying the 255 limit. Messages whose characters and
> bytes agree (ASCII, ISO-8859-1 in an ISO-8859-1 exchange) and messages of at
> most 255 segments are split as before. Module: 141 tests pass.
> Found with a Lean 4 model of the split decision and the segment arithmetic:
> "every short message has at most 140 octets and there are at most 255
> segments" fails on main ({{main_oversize}}, {{main_euros}},
> {{main_256_8bit}}, {{main_256_default}}) and is proved for the fix
> ({{fix_fits}}, {{fix_le_255}}, {{fix_covers_8bit}}); the fix equals main
> whenever main stays within 255 segments ({{fix_eq_main_8bit}},
> {{fix_eq_main_default}}).
> Affected: 4.14.x, 4.18.x and main (same code for years).
> Duplicate check (2026-10-04): JIRA component camel-smpp with split / splitter
> / segment (CAMEL-8013, CAMEL-8116, CAMEL-16134, CAMEL-4086),
> "Smpp8BitSplitter": none on this. GitHub pull requests "smpp split": none.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
