Skip to content

Raw binary request bodies (application/octet-stream) have no typed support #119

@benjamineckstein

Description

@benjamineckstein

Current behavior

A request body declaring only application/octet-stream (raw binary upload, e.g. PUT an image with the bytes as the body) falls back to a plain Illuminate\Http\Request parameter with the generic no-JSON-no-multipart warning. The multipart path types file parts as UploadedFile (#75), but a whole-body raw upload has no typed surface at all.

Why it matters

Raw uploads are a basic pattern (S3-style PUT, image endpoints). Today the developer gets an untyped Request and hand-rolls $request->getContent() with no spec-derived validation (no content-type check, nothing from the schema).

Proposed behavior

Evaluate a typed surface for whole-body binary uploads. Options to weigh:

  1. Keep the Request fallback but make the warning say specifically that the body is a raw binary upload (cheap, honest).
  2. Type the parameter as Illuminate\Http\Request but generate a route middleware or controller-level content-type guard derived from the declared media type.
  3. A small generated value object wrapping the raw stream with the declared media type.

Option 1 is the floor, whether 2 or 3 is worth the complexity is the open question. The existing warned fallback is at least loud, so this is lower priority than the silent response-side issues.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions