Multipart HTTP GET Requests

Enable sandboxed agents to upload media using only HTTP GET requests.

This repo documents an experimental pattern for turning one HTTP POST with a file body into a series of HTTP GET requests: initialize a transfer, send small chunks encoded in HTTP query parameters, then reconstruct and verify the file on the server.

Initially developed for Burning Tokens, a Burning Man for agents, which is meant to be as agent-friendly as possible and allows agents to create and share art.

Verified to work in production across all major agent sandboxes: ChatGPT, Codex, Claude Code, Grokbot, etc as of 9/30/2026.

Why this exists

An agent can generate an image and still have no way to upload it. A sandbox might let one tool read local files while a separate network tool only accepts URLs. Building an agent-friendly service means accommodating that split.

Multipart GET bridges those capabilities. An offline helper reads the file, computes its hash, and produces private request URLs. The agent's URL tool delivers them. This works around a POST/PUT transport limitation when sending the file to that service is authorized; the agent still needs access to the bytes and permission to send them.

This repo documents a proof of concept and a loose pattern you can adapt to your own server. Endpoint names, storage, and limits are implementation choices. “Multipart” means multiple requests here, rather than multipart/form-data.

The whole idea

Choose one upload route based on what the agent's network tool supports: a single HTTP POST or a sequence of HTTP GET requests.

%%{init: {"theme":"neutral","htmlLabels":false,"flowchart":{"htmlLabels":false,"curve":"linear","padding":20,"diagramPadding":16,"nodeSpacing":40,"rankSpacing":40,"wrappingWidth":260},"themeVariables":{"fontFamily":"Arial, sans-serif","fontSize":"16px"}}}%%
flowchart LR
    Q{"HTTP POST<br/>available?"}
    Q -->|Yes| P["HTTP POST<br/>File in request body"]
    Q -->|No| G["HTTP GET only<br/>Start → chunks → complete<br/>Chunks in URL queries"]
    G --> V["Server reassembles<br/>and verifies"]
    P --> U["Uploaded"]
    V --> U

In the GET route, every request has no request body; each chunk's bytes live in a data query parameter. Chunks can arrive out of order. A status request reports missing indices after an interruption. Receiving the last chunk only stages the file: the explicit completion request verifies it and runs the application's normal upload pipeline.

Implementing it on your own server

Give your coding agent this prompt:

Add an optional multipart HTTP GET upload flow to my server for authorized agents whose network tools can only open URLs. Keep ordinary POST uploads.
Use start, part, status, complete, and abort operations. Bind a transfer key to immutable file size, MIME type, SHA-256, chunk size, and owner. Send each chunk as canonical unpadded base64url in query parameters. Make identical retries idempotent; reject conflicting metadata or bytes. On completion, reassemble by index, verify size and hash, and reuse our existing upload validation, authorization, and publication flow with an idempotent commit.
Add bounded storage, expiry, quotas, rate limits, no-store responses, and sensitive-URL log redaction. Keep ordinary GET/HEAD reads nonmutating.
Provide an offline URL-preparation helper and regression tests. Treat this as an experimental compatibility pattern; adapt the details to our stack.

Reference: https://github.com/transitive-bullshit/multipart-http-get-requests

Read the pattern guide for example requests, retry behavior, limits, and implementation notes.

The trade-offs

• GET writes break HTTP's safe-method semantics. Private capabilities, explicit intent, and idempotency reduce accidental effects, but link scanners and prefetchers remain a concern. Prefer POST when available. HTTP semantics.
• URLs contain the upload. File bytes and credentials can enter logs, history, and tool transcripts. Use HTTPS, scoped credentials, cache bypass, and URL redaction; no-store alone does not ensure privacy. HTTP caching.
• Small chunks mean many requests. At 4 KiB per chunk, a 100 KiB image takes 27 requests including start and complete; a 2 MiB file takes 514. Optimize media first.
• Compatibility depends on the whole toolchain. URL length limits, tool-call budgets, and access to actual file bytes all matter. A sandbox attachment link alone is insufficient.

Try it live with your own agent

Send your agent to Burning Tokens →

Create a visit, give your agent its private invitation, and ask it to make a small piece of art in the Open Studio. The invitation's instructions explain the available upload routes, including multipart GET for URL-only tools. Ask for the final artifact receipt so you can see what was actually stored and shared.

The production project's source and offline upload helper show the pattern in practice. See the reference implementation notes for the source snapshot and its limits. Support in one agent harness does not establish support in every other harness.

License

MIT © Travis Fischer.

Want to improve the pattern or document another implementation? See contributing.md.