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

[Innovarzweng]

Hi @vinodaravind01 ,

Thanks for reporting this!

Could you please provide additional details, such as the JavaScript code and screenshots? The Innovar team will attempt to reproduce the issue in our development environment.

It's possible that BridgeLink is struggling to parse large ZIP files due to memory constraints on the machine. We can also look into allocating more memory to that specific box to see if it resolves the issue.

Thanks, Jim

[vinodaravind01]

Hi Jim,

Thanks for the quick response.

We’ve already narrowed this down quite a bit and wanted to share our findings clearly.

---

JavaScript Code

The JavaScript itself is very simple and works correctly when BridgeLink parses the multipart payload properly. Below is the source transformer we are using when attachments are enabled:

///////////////////////////////////////////////////////////////////////////
// SOURCE TRANSFORMER – MULTIPART ZIP (WORKING BUT CORRUPTED FOR LARGE FILES)
///////////////////////////////////////////////////////////////////////////

var attachments = getAttachments(false);

if (attachments == null || attachments.size() === 0) {
    setErrorResponse(400, "No file attachment received");
    throw "No multipart attachment found";
}

var attachment = attachments.get(0);
var bytes = attachment.getContent();

if (bytes == null || bytes.length === 0) {
    throw "Empty ZIP payload";
}

channelMap.put("attachmentBytes", bytes);
channelMap.put("attachmentFilename", "uploaded.zip");

logger.info(
    "Attachment size=" + bytes.length +
    ", first 4 bytes=" + bytes[0] + "," + bytes[1] + "," + bytes[2] + "," + bytes[3]
);

msg = "<ok/>";

No additional decoding or manipulation is performed in JavaScript.

---

Why This Does Not Appear to Be a Memory Issue

We tested using:

• Small ZIP files
• Large ZIP files
• curl
• httpyac
• Raw ZIP uploads (non-multipart)

Key observations

• When sent as multipart/form-data with
  Summary → Attachment → Entire Message, the ZIP becomes corrupted before JavaScript processing.

• Logged first bytes for corrupted payloads:

  45,45,45,45   ("----")
  76,83,48,116  ("LS0t" → Base64-encoded multipart boundary)
  

• A valid ZIP should always start with:

  80,75,3,4  (PK)
  

This indicates that multipart boundary or Base64-related content is leaking into the attachment byte stream.

Additional observations:

• The reported attachment size is consistently larger than the original ZIP
• In some cases, the first bytes look correct, but the end of the ZIP (central directory) is corrupted
• The issue reproduces consistently and deterministically, regardless of file size

Because:

• Small files also reproduce the issue
• Memory usage does not spike
• Corruption patterns match multipart parsing artifacts

…it does not appear to be related to JVM memory pressure.

---

Screenshots

I am attaching screenshots of:

• HTTP Listener settings
• Summary → Attachment → Entire Message configuration

---

Summary

This appears to be a multipart parsing issue in the HTTP Listener when using
Attachment → Entire Message, where binary ZIP data is not preserved byte-for-byte.

Please let us know if there is:

• A recommended UI configuration for binary multipart uploads, or
• A way to disable multipart parsing and safely access the raw request bytes

Happy to help with further reproduction steps if needed.

Thanks again,
Vinod

[dsvanstedt]

@vinodaravind01 - how can we test this? Do you have a suggestion how to simulate the Sender?