Skip to content

Conversation

@bjohansebas
Copy link
Member

Before #57 and in #58, if there were multiple ranges and some of them were valid, they would still be shown. at least this way those changes aren’t a completely breaking change.

@bjohansebas bjohansebas changed the title fix: still show ranges if there are multiple ranges, even if some are… fix: still show ranges if there are multiple ranges, even if some are invalid Jan 23, 2026
Comment on lines 11 to 15
it('should return -2 for range missing dash', function () {
assert.strictEqual(parse(200, 'bytes=100200'), -2)
assert.strictEqual(parse(200, 'bytes=,100200'), -2)
assert.strictEqual(parse(200, 'bytes=100-200,100200'), -2)
})
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to get the coverage to 100%, it has nothing to do with my changes

index.js Outdated
Comment on lines 53 to 56
// ignore empty/whitespace-only ranges if there are other valid ranges
if (arr.length > 1 && arr[i].trim() === '') {
continue
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This handles a case where the range can be 'bytes= , 0-10', which before the two PRs was valid and returned ranges, but without this patch it returns -2.

@bjohansebas
Copy link
Member Author

another case that used to work before the previous two PRs, but no longer does now

var range = parse(1000, 'bytes= d ,20-30')

assert.strictEqual(range.type, 'bytes')
assert.strictEqual(range.length, 1)
deepEqual(range[0], { start: 20, end: 30 })

@blakeembrey
Copy link
Member

blakeembrey commented Jan 23, 2026

I'm going to edit this PR, it's a bit too complex and contains edge cases. Any time you're trying to check lengths of things and have a bunch of branches like this it's going to contain subtle problems, it's a lot easier to rely on the parser that's already written. It's why I got rid of the length checks in #58 (it had bugs for whitespace and other characters).

The simplest approach is to just keep a return code value and alter it during parsing results, then return it as the end.

Finally, I think back porting the code from #62 should be the final outcome here, since it doubled performance instead of reducing it, while also improving correctness.

it('should return -2 for range missing dash', function () {
assert.strictEqual(parse(200, 'bytes=100200'), -2)
assert.strictEqual(parse(200, 'bytes=,100200'), -2)
assert.strictEqual(parse(200, 'bytes=100-200,100200'), -2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once I removed the return this failed but arguably should be working, 100-200 is valid.

assert.strictEqual(parse(200, 'bytes=500-600,x-'), -1)
assert.strictEqual(parse(200, 'bytes=x-,500-600'), -1)
assert.strictEqual(parse(200, 'bytes=500-600,900-'), -1)
assert.strictEqual(parse(200, 'bytes=900-,500-600'), -1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto for this test, 500-600 is valid. I think this test is just invalid now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn’t it supposed to be out of range? And is that why it’s -1?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a -1 this is already being tested above.

Copy link
Member

@blakeembrey blakeembrey Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your PR previously had it as -2. Misremembered, my edit changes it to a -2. I can go either way I guess, but I'd err to simplicity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the test back, do you need invalid and unsatisfiable to return -1?

Copy link
Member Author

@bjohansebas bjohansebas Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should still return -1. There’s a valid range, but it exceeds the allowed bounds, so it should return -1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member Author

@bjohansebas bjohansebas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@blakeembrey blakeembrey merged commit b49e00f into jshttp:master Jan 23, 2026
28 checks passed
@bjohansebas bjohansebas deleted the more-spec branch January 23, 2026 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants