ZIP file corrupted when using HTTP Listener attachments (Entire Message)

[vinodaravind01]

Description

We are receiving ZIP files via the BridgeLink HTTP Listener using multipart/form-data.
The JavaScript transformer logic is correct and verified, but the ZIP file appears to be corrupted during source parsing, before JavaScript processing.

Observed Behavior

• ZIP file size becomes larger than the original after BridgeLink parses it
• In most cases, the ZIP signature (PK) is missing at the beginning
• In one scenario, the ZIP header (PK) is correct, but the ZIP fails validation due to corrupted trailing bytes
• Different clients (curl, httpyac) result in different corruption patterns
• Issue occurs when Attachments → Entire Message is enabled
• HTTP Listener UI exposes only Binary MIME Types, with no additional multipart/attachment parsing options

Expected Behavior

• Multipart ZIP uploads should be preserved byte-for-byte
• ZIP header (PK) and trailer should remain intact
• Parsed attachment bytes should exactly match the uploaded file

Impact

• Valid ZIP files are rejected as invalid or corrupted
• Downstream services fail ZIP validation
• Multipart ZIP ingestion is unreliable

Suspected Cause

• Missing or insufficient HTTP Listener configuration for multipart binary handling
• Potential issue or limitation in attachment parsing when using Entire Message

Request

• Guidance on correct HTTP Listener settings for multipart ZIP uploads
• Confirmation whether this is a known limitation or bug
• Recommendation for an alternative configuration if available