getsentry / getsentry/sentry

Enable multipart/form-data POST Request Monitoring with Binary File Upload (e.g., Audio/Image)

Open
#96,826 3 comments 0 reactions 0 assignees View on GitHub
Product Area: Crons Uptime
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
22h 21m
Merged PRs (30d)
586

Description

### Problem Statement

#### Description of the Problem:

Our API endpoints commonly accept HTTP POST requests formatted as multipart/form-data, which include binary file uploads (e.g., .wav audio files, images). Current Uptime Monitor capabilities appear to be limited to text-based request bodies (like JSON or simple key-value pairs), or they have strict overall size limits (e.g., 1000 bytes) that make it impossible to include even a minimal binary file for testing.

This limitation prevents us from performing comprehensive end-to-end uptime monitoring of our critical API functionalities that rely on file uploads. We cannot truly verify if our file upload mechanisms are working correctly without actually sending a representative binary payload.

#### How This Would Help Our Workflow:

Implementing this feature would significantly improve our ability to:

- Ensure End-to-End API Health: Beyond just checking if the server is up, we can verify that the critical file upload pipeline of our API is functional and responsive. This is crucial for applications that depend heavily on receiving and processing user-uploaded content.
- Catch Failures Earlier: Issues with file parsing, storage, or processing on the server-side that might not be caught by a simple JSON or GET request health check would be identified immediately.
- Reduce False Negatives/Positives: Avoid relying solely on simpler health checks that might pass even if the core file upload functionality is broken.
- Streamline Monitoring Stack: Consolidate monitoring efforts within a single platform, rather than needing custom scripts or external synthetic monitoring tools for this specific use case.

This feature would be invaluable for modern web services that handle user-generated content and binary data uploads. We believe it would greatly enhance the utility of your Uptime Monitor for a wide range of users.

### Solution Brainstorm

#### Proposed Solution / Desired Feature:

We request the ability to configure Uptime Monitor checks that can:

1. Construct `multipart/form-data` POST requests: Allow the user to define multiple form-data parts, including:

- Text fields: Standard `name=value` pairs.
- File fields: Specifically, the ability to specify a `name` for the file parameter (e.g., `audio`), a `filename` (e.g., `test.wav`), and the `Content-Type` (e.g., `audio/wav`).

2. Upload Small Binary Payloads: Provide a mechanism to include a small, pre-defined binary payload (e.g., a few hundred bytes of static WAV or image data) as part of a multipart/form-data request. This could be achieved by:

- Allowing users to upload a small sample file directly within the monitor configuration.
- Providing a text area where users can input Base64-encoded binary data, which the monitor would then decode and include as the binary part of the multipart/form-data request.

3. Support for Larger `Content-Length` (Optional, but ideal for real-world testing): While 1000 bytes might be sufficient for a basic "is it alive?" check with a tiny file, an increased overall HTTP request size limit would greatly enhance the realism and effectiveness of such tests for actual file upload APIs.

### Product Area

Alerts

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are named. Start by locating the Uptime Monitor request configuration and request-size validation, then determine how multipart fields and binary data are represented. Done should include a configurable multipart/form-data check that accepts text and binary parts within a documented size limit.

Written by the indexing model from the issue text.

Assessment

Domain
observability-sre
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.