application/octet-stream webhook body is silently dropped and forwarded as empty {}

[slzr23]

application/octet-stream webhook body is silently dropped and forwarded as empty {}

Description

When a webhook is sent to a Smee channel with Content-Type: application/octet-stream and a binary body, the payload is lost. The Smee UI displays an empty event, and the smee-client forwards an empty body {} to the local server.

Steps to reproduce

1. Create a Smee channel at https://smee.io

2. Start a local listener:

const EventSource = require('eventsource');

const smeeUrl = 'https://smee.io/YOUR_CHANNEL';
const events = new EventSource(smeeUrl);

events.onmessage = (msg) => {
  const data = JSON.parse(msg.data);
  console.log('Received body:', data.body);
};

3. Send a binary webhook to the channel:

curl -X POST https://smee.io/YOUR_CHANNEL \
  -H "Content-Type: application/octet-stream" \
  --data-binary $'\x00\x01\x02\x03\xde\xad\xbe\xef'

Expected behavior

The binary body is forwarded to the local listener, either as a base64-encoded string or as a raw buffer, preserving the original content.

Actual behavior

The Smee UI shows the event with an empty payload:

{ "1234567890": {} }

The local listener receives data.body = {} — the binary body is silently dropped.

Root cause (analysis)

Smee serializes the incoming HTTP request as a JSON SSE event. When the body is binary (application/octet-stream), it cannot be directly embedded in JSON. There is no fallback encoding (e.g. base64), so the body becomes null or {}.

Suggested fix

When Content-Type: application/octet-stream is detected, encode the binary body as base64 in the SSE event and add a flag so clients can decode it:

{
  "body": "AAECAw==",
  "body_encoding": "base64",
  "headers": { "content-type": "application/octet-stream" }
}

Environment

• smee-client: 1.2.3
• Node.js: 22

[wolfy1339]

We only accept JSON payloads on purpose.

As for silently dropping other formats, that can be fixed.

However we (current contributors) don't have access to deploy any code to the smee.io server

[slzr23]

I understand the focus on JSON. However, since the server currently accepts the request with a 200 OK but forwards an empty object, it creates a very confusing debugging experience.

If a fix can be merged even if not deployed immediately, would you consider a PR that either:

• Implements the base64 fallback for non-JSON payloads?
• Or at least returns a 415 error code when the Content-Type is not supported, to avoid silent data loss?

I'm willing to contribute the code if you can point me to the right direction.

[wolfy1339]

Absolutely a PR is welcome.

The server code lives in https://github.com/probot/smee.io/blob/master/lib%2Fserver.js

GitHub

smee.io/lib/server.js at master · probot/smee.io

☁️📦 Webhook payload delivery service. Contribute to probot/smee.io development by creating an account on GitHub.

[wolfy1339]

Although I think that has been fixed in some of the refactoring done locally, as fastify doesn't handle everything by default

[slzr23]

Thanks for the pointer! I'll take a look at lib/server.js. Even if Fastify handles payloads differently, implementing a explicit base64 fallback for application/octet-stream would ensure the data is safely transported via SSE without being dropped. I'll try to put together a PR for this.