-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add maxReturnSize
option
#90
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review. I added tsd
tests for maxChunkSize
and acceptRanges
.
Could you take another look?
Is a maxChunkSize not basically a highWatermark? Should we name it like that? |
I don't think that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 6 out of 6 changed files in this pull request and generated no suggestions.
Comments skipped due to low confidence (2)
test/utils.js:12
- The function name should be 'shouldHaveHeader' instead of 'shouldNotHaveHeader'.
module.exports.shouldHaveHeader = function shouldNotHaveHeader (header, t) {
README.md:52
- The heading should be 'maxChunkSize' instead of 'acceptRanges'.
##### acceptRanges
maxChunkSize
option to SendOptions
maxChunkSize
option
Co-authored-by: Frazer Smith <[email protected]> Signed-off-by: Kaede Fujisaki <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review and typo suggestion!
Could you take another look?
The name is not that nice. maxChunkSize is imho a |
lib/send.js
Outdated
@@ -546,6 +551,9 @@ function sendFileDirectly (request, path, stat, options) { | |||
|
|||
// Content-Range | |||
statusCode = 206 | |||
if (options.maxChunkSize) { | |||
ranges[0].end = Math.min(ranges[0].end, ranges[0].start + options.maxChunkSize - 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesnt seem right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some unit tests that success, so I think you are pointing out some edge cases that cause bug. If so, could you tell me the condition or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
preemptive blocker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a problem here.
In your request headers Range: bytes=0-
means send me a file starting with bytes 0 to the end of the file.
And the response is actually does what it is requested.
Partial content return should be controlled by the request (client), not the response (server) to limit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review. I renamed to highWatermark
.
lib/send.js
Outdated
@@ -546,6 +551,9 @@ function sendFileDirectly (request, path, stat, options) { | |||
|
|||
// Content-Range | |||
statusCode = 206 | |||
if (options.maxChunkSize) { | |||
ranges[0].end = Math.min(ranges[0].end, ranges[0].start + options.maxChunkSize - 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some unit tests that success, so I think you are pointing out some edge cases that cause bug. If so, could you tell me the condition or something?
@climba03003 Thanks for the comment. Here is the latest rfc(9110). Here is a from
So, I think this PR's behavior is, at least, compatible with RFC. |
Yes, a very rare use-case.
|
Thanks for understanding and naming recommendations! I choiced |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Signed-off-by: Frazer Smith <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a bug fix no? Shouldn't it be on by default?
Cc @climba03003 |
It is not a bugfix, but a feature request. By default, it should return as requested by the client. |
Oh I misunderstood
I thought the server wasn't respecting the range headers or sth |
Hi. I'm the author. I think this is not a bug fix. (Please see the title: it starts with #90 (comment)
|
Currently, this library tends to send entire file when
'acceptRanges': true,
In this PR, I added
maxChunkSize
tosend.SendOptions
to limit the max chunk size.Test case: https://hexe.net/2022/09/17/17:04:55/
Souce code is here
I'm using firefox 132.0.
Request:
Response:
I also checked in MS Edge 131.0.2903.51.
Checklist
npm run test
andnpm run benchmark
npm run benchmark
commandand the Code of conduct