Enable multipart/form-data POST Request Monitoring with Binary File Upload (e.g., Audio/Image)
- 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
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