[blakeembrey]

Opening to get opinions, but I prefer this approach as the output shape doesn't get changed on you and it gives the caller more flexibility.

Current behavior is to always return an object when anything is parsed successfully, and silently drop the ranges that failed. If nothing parsed or is valid, return a negative number.

With this approach, the shape always stays the same and a caller can choose either to reject things that parse incorrectly (any non-zero code) or use ranges.length like we currently do.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (5a27c8d) to head (83c73cc).

Additional details and impacted files

@@            Coverage Diff            @@
##            master       #71   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines           68        81   +13     
  Branches        17        23    +6     
=========================================
+ Hits            68        81   +13     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yxshee]

I like the fixed return shape. Callers like send currently branch on -1/-2 and then on .length, so one object with a code is easier to get right. I ran the branch and found two things:

1. Empty list elements set code: 1, but only when they aren't at the end.

   parse(100, "bytes=0-1,,2-3")  // code 1, both ranges returned
   parse(100, "bytes=,0-1")      // code 1
   parse(100, "bytes=0-1,")      // code 0

   RFC 9110 section 5.6.1.2 says a recipient MUST accept and ignore empty list elements, so all three should probably be code: 0. Otherwise a caller that takes the "reject any non-zero code" option rejects a valid header. I think bytes= , , (no elements at all) should stay malformed.

2. The README example checks subranges.length, which is always undefined on the result object, so the forEach never runs. It should be subranges.ranges.length, like the combineRanges example below it.

Also, #72 changes the same two whitespace lines (it accepts HTAB as OWS), so whichever lands second will need a small rebase. I'm happy to do that on my side.

[bjohansebas]

I like this way of returning the data

[yxshee]

I like the fixed return shape. Callers like send currently branch on -1/-2 and then on .length, so one object with a code is easier to get right. I ran the branch and found two things:

1. Empty list elements set code: 1, but only when they aren't at the end.

   parse(100, "bytes=0-1,,2-3")  // code 1, both ranges returned
   parse(100, "bytes=,0-1")      // code 1
   parse(100, "bytes=0-1,")      // code 0

   RFC 9110 section 5.6.1.2 says a recipient MUST accept and ignore empty list elements, so all three should probably be code: 0. Otherwise a caller that takes the "reject any non-zero code" option rejects a valid header. I think bytes= , , (no elements at all) should stay malformed.

2. The README example checks subranges.length, which is always undefined on the result object, so the forEach never runs. It should be subranges.ranges.length, like the combineRanges example below it.

Also, #72 changes the same two whitespace lines (it accepts HTAB as OWS), so whichever lands second will need a small rebase. I'm happy to do that on my side.

[blakeembrey]

Rolled the fixes into this PR, it was necessary to better handle some other edge cases too.

The only awkward feature now is that inclusive start/end makes it zero length files required to have an empty ranges but zero code. I think that's fine, but @bjohansebas do you have any opinions on inclusive vs exclusive end?

Personally exclusive end is more intuitive, but inclusive lines it up with the spec better and avoids foot guns during the major upgrade.