Conversation
…s not a file
Uploads were the one corner of this API a generated client could not use. The
spec described `POST /api/uploads` as taking a property named `file` with no
type at all, so nothing could tell it wanted a file, and the URL that route
hands back pointed at `GET /api/uploads/{filename}`, which was registered as a
plain route and therefore never appeared in the document — a client could upload
by guesswork and then had no declared path to read the file back. Both are now
declared: the form part carries the standard binary spelling, and the serving
route is in the spec with its path parameter, a media-range body for the stored
bytes, and its 404.
The upload handler also cast the form part to a file without checking. A text
part named `file` satisfies the request schema, so it reached `.arrayBuffer()`
and came back as a 500. It is now an instance check, which is the 400 the route
already meant to return and, until now, could not declare — that undeclared 400
was the repository's only type error.
Nothing that worked before changes. The app's own uploader sends a real file and
takes the same round trip: 200 with the URL, then the file back with its own
content type and the immutable cache header, and a 404 for a filename that is
not stored.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uploads were the one corner of this API a generated client could not use.
The upload field had no type.
POST /api/uploadspublished itsfileproperty as
{}— nothing in the document said it wanted a file. It now carriesthe standard multipart spelling:
The route that serves the file was not in the spec at all. The upload
response hands back a URL under
/api/uploads/{filename}, but that route wasregistered as a plain route, so it never reached
/api/openapi.json. A clientgenerated from the spec could follow the URL it had just been given only by
guessing. It is now declared with its path parameter, a media-range body for the
stored bytes, and its 404.
A text part named
filereturned a 500. The handler cast the form part to afile without checking, so a string satisfied the request schema and then blew up
on
.arrayBuffer(). It is now an instance check, which returns the 400 the routealready meant to return — and declaring that 400 clears the repository's only
type error.
Verified
Against the real app, with the storage binding stubbed:
200{ url, filename }200, original bytes, original content type, immutable cache header404400 { "error": "No file" }(was500)filepart400from request validationtsc --noEmitis clean; it was not before. The app's own uploader sends a realfile and is unaffected.