René's URL Explorer Experiment

Title: feat: Support streaming request bodies by thced · Pull Request #131 · extenda/openapi-httpserver-java · GitHub

Open Graph Title: feat: Support streaming request bodies by thced · Pull Request #131 · extenda/openapi-httpserver-java

X Title: feat: Support streaming request bodies by thced · Pull Request #131 · extenda/openapi-httpserver-java

Description: Summary Request bodies were always buffered in memory (readAllBytes). This adds opt-in streaming, so a handler can take large uploads without holding them in memory. StreamingRequestHandler — a handler implementing it gets the body unread via request.bodyStream(). The Content-Encoding (gzip built in) is decoded lazily under a size cap; StreamingRequestHandler.raw(...) skips decoding and hands over the bytes as sent. bytes() / parsed() / asPojo() throw on a streaming request. Still checked before the handler runs: routing, parameter validation, security, a required body being present (one-byte peek) and the Content-Type matching requestBody.content. The body schema is not validated (it can't be without buffering). Builder.maxConcurrentStreamingRequests(n[, retryAfter]) — optional server-wide cap; excess streaming requests get 503 problem+json with Retry-After. The slot is taken after security and the peek, so slow or unauthenticated clients never hold one. Buffered requests are not counted. After-response hooks see the 503. Builder.maxDecompressedStreamingRequestBytes(long) — a separate cap on the decoded size of a streamed body; any positive long, so past the 2 GiB that bounds buffered bodies (maxDecompressedRequestBytes, held in a byte[]). Defaults to maxDecompressedRequestBytes. Content-Type matching (both paths): media ranges type/* and */* in requestBody.content; a missing Content-Type is treated as application/json if declared, else application/octet-stream (RFC 9110 §8.3). Request.headers() — all request headers, case-insensitive. Streaming extra routes (extraRoute with a StreamingRequestHandler) are supported and share the concurrency cap. A streaming handler on an operation without a requestBody fails at boot. Additive only; existing handlers behave as before. One 400 detail string for a missing Content-Type now names application/octet-stream when JSON isn't declared. Design and plan: docs/superpowers/specs/2026-10-08-streaming-request-bodies-design.md, docs/superpowers/plans/2026-10-08-streaming-request-bodies.md. README has a new "Streaming request bodies" section. Known limits (documented) A buffered 404/405 is still answered after reading the full body (unchanged from master). Clients sending Expect: 100-continue are answered 100 by the JDK before filters run, so a shed client may still send its body. Test plan mvn verify — 758 unit + 128 IT green (incl. 36 in StreamingRequestBodyIT: 8 MiB past the cap, gzip, 413/400/415, separate streaming cap, validation, security, cap + Retry-After, slot release on failures, stalled clients holding no slot) pre-commit hooks pass SonarLint clean on changed files

Open Graph Description: Summary Request bodies were always buffered in memory (readAllBytes). This adds opt-in streaming, so a handler can take large uploads without holding them in memory. StreamingRequestHandler — a ha...

X Description: Summary Request bodies were always buffered in memory (readAllBytes). This adds opt-in streaming, so a handler can take large uploads without holding them in memory. StreamingRequestHandler — a ha...

Opengraph URL: https://github.com/extenda/openapi-httpserver-java/pull/131

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width