Repository navigation
Conversation
This branch has not been deployed
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
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.
The octet-stream upload path skips three of the checks that multipart uploads get in
_handlePart():filter,allowEmptyFilesandminFileSize. This is the follow-up to #1113, which addsmaxFileSizeandmaxTotalFileSizeto the same path.Steps to reproduce
Measured on
master(9ee1247), sending the same body asapplication/octet-streamand as one multipart file:filter: () => falsefilternot called, file savedfiltercalled, file skippedminFileSize: 1000smallerThanMinFileSize)allowEmptyFiles: false)Transfer-Encoding: chunkednoEmptyFiles)With
Content-Length: 0the octet-stream plugin is never reached, because the request gets theDummyParser, so an empty body returns no file and no error. That path is unchanged.Fix
In
src/plugins/octetstream.js:options.filteris called with{ name: "file", originalFilename, mimetype }before the file is created.nameis"file"because that is the key the octet-stream file is returned under. When it returnsfalse, the body is read and discarded, and the parse ends with no file and no error, as the README describes forfilter.allowEmptyFilesandminFileSizeare checked againstbytesReceived, since the octet-stream body is the file, with the same error codes, messages and order as_handlePart(). The checks run beforethis.endedis set, because_error()ignores errors after that. On error the partial file is removed by the shared_error()cleanup.With default options any non-empty body behaves as before. The only change with defaults is an empty chunked body, which now fails with
noEmptyFiles, like an empty multipart file.Tests
test/integration/octet-stream-file-checks.test.js:filterreturningfalse: no error, no files, andfiltercalled once with the expected argumentminFileSize: 1000with 10 bytes: error 1008 and no filesallowEmptyFiles: true, minFileSize: 0: one empty file, as with multipartThe first three fail on
master. Removing any of the new checks fails at least one of them.Suite status: 98 passed / 3 skipped across 16 jest suites, and 11/11 node tests. The new tests use their own ports. This PR and #1113 merge cleanly in either order.


Confidence Score: 5/5
The PR appears safe to merge.Summary
The PR applies
filter,allowEmptyFiles, andminFileSizeto octet-stream uploads.Reviews (2) · Last reviewed commit: "test: remove uploaded files after octet-..." · Reviewed by Greptile