gitroomhq/postiz-app · error · BadBody

The media storage did not return the requested byte range, p

Error message

The media storage did not return the requested byte range, please try again

What it means

tiktokChunkStream expected a 206 Partial Content response when requesting a byte range from media storage, but got another status (typically 200 or an error page). This guards the chunked upload against stores that ignore the Range header, which would corrupt the video data written at that offset.

Source

Thrown at libraries/nestjs-libraries/src/integrations/social/tiktok.provider.ts:709

  // Returns a streaming body for the [start, end] byte range of the media so we
  // never hold the whole file in memory: a ranged GET for remote URLs, a ranged
  // read stream for local files.
  private async tiktokChunkStream(path: string, start: number, end: number) {
    if (path.indexOf('http') === 0) {
      // identity encoding so the store keeps content-length and can answer
      // with the requested range, matching every other media read
      const response = await fetch(path, {
        headers: {
          Range: `bytes=${start}-${end}`,
          'accept-encoding': 'identity',
        },
        dispatcher: getSsrfSafeDispatcher(),
      } as any);

      // A store that ignores Range (200 with the full file) or answers with an
      // error page would corrupt the upload at this offset.
      if (response.status !== 206) {
        throw new BadBody(
          'tiktok-error-upload',
          '{}',
          '{}',
          'The media storage did not return the requested byte range, please try again'
        );
      }

      return response.body;
    }

    return createReadStream(path, { start, end });
  }

  // Streams the video bytes to the upload_url returned by the init call.
  // We use the global fetch (not this.fetch) because chunked uploads answer
  // with 206 (Partial Content), which this.fetch would treat as an error.
  private async uploadTikTokVideoBytes(
    uploadUrl: string,

View on GitHub (pinned to 0f1647f749)

Solutions

  1. Verify the media URL returns 206 with curl: curl -H 'Range: bytes=0-1023' -I <media-url>
  2. If storage ignores Range, fix its configuration (enable range support / use a store that supports it) so chunked upload is possible
  3. Regenerate/re-upload the media so the presigned URL is fresh, then retry the post
  4. If the media is small enough, let TikTok use non-chunked upload instead of tiktokChunkStream

Example fix

// before
const response = await fetch(url, { headers: { Range: `bytes=${start}-${end}` } });
const chunk = await response.arrayBuffer(); // corrupt if status is 200

// after
const response = await fetch(url, { headers: { Range: `bytes=${start}-${end}` } });
if (response.status !== 206) {
  throw new BadBody('tiktok-error-upload', '{}', '{}',
    'The media storage did not return the requested byte range, please try again');
}
Defensive patterns

Strategy: validation

Validate before calling

const resp = await fetch(mediaUrl, { method: 'HEAD' });
const acceptRanges = resp.headers.get('accept-ranges');
if (!acceptRanges?.includes('bytes')) {
  // avoid chunked upload path or copy media to range-capable storage first
}

Type guard

const isRangeResponse = (r: Response): boolean => r.status === 206 && r.headers.has('content-range');

Try / catch

catch (e) { if (e instanceof BadBody && e.message.includes('byte range')) { /* refetch media URL / re-upload media, then retry once */ } throw e; }

Prevention

When it happens

Trigger: A GET with a Range header against the media URL returns 200 (full file), 4xx/5xx, or a proxy/WAF HTML page instead of 206. Happens with media-storage presigned URLs that don't support ranges, expired signed URLs redirecting to a login page, or CDNs stripping the Range header.

Common situations: Self-hosted or S3-compatible storage misconfigured for range requests; expired presigned media URLs; a reverse proxy in front of storage that drops Range headers; uploading large TikTok videos >~64MB which force chunked mode.

Related errors


AI-assisted analysis of gitroomhq/postiz-app@0f1647f749 (2026-08-27). Data as JSON: /api/errors/a2dbd5699f29c6fa. Report an issue: GitHub.