Skip to content

feat: answer multiple ranges with a multipart/byteranges body - #2496

Open
alexander-akait wants to merge 6 commits into
mainfrom
feat/multipart-range-requests
Open

alexander-akait wants to merge 6 commits into
mainfrom
feat/multipart-range-requests

Conversation

@alexander-akait

@alexander-akait alexander-akait commented Oct 23, 2026 •

Copy link
Copy Markdown
Member

Closes #1229.

A Range header that asks for more than one range (bytes=0-99,5000-5099) used to get the whole file with 200 and an error in the log. It now gets 206 Partial Content with a multipart/byteranges body, as RFC 9110 §14.6 describes:

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=1adf6d3adde1b56a06754e02
Content-Length: 412

--1adf6d3adde1b56a06754e02
Content-Type: text/javascript; charset=utf-8
Content-Range: bytes 0-99/48213

…100 bytes…
--1adf6d3adde1b56a06754e02
Content-Type: text/javascript; charset=utf-8
Content-Range: bytes 5000-5099/48213

…100 bytes…
--1adf6d3adde1b56a06754e02--

Details:

  • Ranges that overlap or touch are merged first by range-parser (combine: true, as before), so bytes=0-499, 499-800 is still a single-range 206. Parts keep the order they were asked in.
  • Each range is streamed from the output file system in turn, through a Readable over an async generator that opens one range's stream at a time. Asking for a few slices of a large asset (the use case in the issue) reads only those slices.
  • Parts are cut from a buffer instead when a strong ETag already read the whole file, or when the file system has no createReadStream.
  • Content-Length is exact. HEAD gets the headers only. A stale If-Range still gets the full 200.
  • Content-Type is removed before it is set: on Hono, setting a header adds a value, which the tests caught.
  • modifyResponseData receives the multipart body as a stream; the README note says so.

Tests, in test/middleware.test.js and run on every framework:

  • GET with two ranges in reverse order: both parts, their headers and bodies, the exact Content-Length, no top-level Content-Range.
  • HEAD with two ranges.
  • Strong ETag: parts cut from the read file. A stale If-Range falls back to 200.
  • No createReadStream: parts cut from readFileSync.
  • The old test, which asserted the 200 fallback, now asserts the 206.

Results: test/middleware.test.js passes 6681/6681. The full unit suite has 7424 passed. The 2 failures are the writeToDisk EACCES cases, which fail on main too when run as root. npm run lint passes, including types and spelling (byteranges added to .cspell.json).

A minor changeset is included. This isn't breaking: a client that sends several ranges has to accept a multipart answer under the spec, and the full 200 was only ever a fallback.


Generated by Claude Code

Summary by CodeRabbit

  • New Features
    • Requests for multiple byte ranges now receive a 206 Partial Content response with a multipart/byteranges body. Overlapping or adjacent ranges are combined, and parts follow request order with content type and range details.
    • Multipart responses work with streamed or buffered file data. A stale If-Range condition continues to return the full response.
  • Bug Fixes
    • Requests with more than 200 ranges return the full file. Read failures before response headers are sent return an error response; failures after streaming begins close the connection.
  • Documentation
    • Clarified that range requests may return a stream, including multipart streams for multiple ranges.

A Range header with more than one range (after range-parser merges the
ones that overlap or touch) now gets 206 Partial Content with a
multipart/byteranges body (RFC 9110, section 14.6) instead of the whole
file. Each range is streamed from the output file system in turn, or cut
from the buffer a strong ETag already read.

Closes #1229

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA
@changeset-bot

changeset-bot Bot commented Oct 23, 2026 •

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 6152bd1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
webpack-dev-middleware Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@coderabbitai

coderabbitai Bot commented Oct 23, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 5e73ee7c-39f1-47f3-9adc-c51e4ced6bba
📥 Commits

Reviewing files that changed from the base of the PR and between afe44d1 and 6152bd1.

📒 Files selected for processing: 3
  • .changeset/multipart-range-requests.md
  • src/middleware.js
  • test/middleware.test.js
🚧 Files skipped from review as they are similar to previous changes: 1
  • .changeset/multipart-range-requests.md

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review.

Walkthrough

The middleware now handles multiple byte ranges with a 206 multipart response, subject to a 200-range limit. A new helper builds multipart bodies as buffers or readable streams and calculates their byte length. Tests cover GET and HEAD responses, stale If-Range values, strong ETags, read failures, and output file systems without createReadStream. Response-data types now accept general readable streams.

Priority: ➖ Normal

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 6152b

The previously identified range-limit, ordering, and callback-type issues are corrected. No actionable merge-blocking risk remains after normal checks.

Pre-merge checks: Passed 5
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely describes the main change: support for multiple range requests with a multipart/byteranges response body.
Linked Issues check Passed Issue #1229 requests multipart range support. The reviewed-head evidence shows 206 Partial Content with a multipart/byteranges body for multiple ranges. The implementation merges overlapping or to…
Out of Scope Changes check Passed The changes remain connected to issue #1229. Middleware and utility changes implement multipart responses. Tests verify the feature and stream error behavior. README and type updates document the mult…
Docstring Coverage Passed Docstring coverage is 81.82% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 6 files. (1 skipped: 1 …
Full details: Linked Issues check

Explanation

Issue #1229 requests multipart range support. The reviewed-head evidence shows 206 Partial Content with a multipart/byteranges body for multiple ranges. The implementation merges overlapping or touching ranges and preserves the first requested range order. It streams one range at a time when possible and uses buffered parts when required. It also handles HEAD, exact Content-Length, stale If-Range, strong ETag, filesystems without createReadStream, and the 200-range fallback. Tests cover these behaviors across the supported frameworks.

Full details: Out of Scope Changes check

Explanation

The changes remain connected to issue #1229. Middleware and utility changes implement multipart responses. Tests verify the feature and stream error behavior. README and type updates document the multipart stream contract. The changeset and spelling entry support the same feature. No unrelated change is demonstrated by the supplied evidence.

Full details: Docstring Coverage

Explanation

Docstring coverage is 81.82% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 6 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Some tools did not complete. Review the errors below.

🔧 ast-grep (0.45.3)
test/middleware.test.js

ast-grep timed out on this file

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

test/middleware.test.js

Oops! Something went wrong! :(

ESLint: 9.39.5

Error: Error while loading rule 'jest/no-deprecated-functions': Unable to detect Jest version - please ensure jest package is installed, or otherwise set version explicitly
Occurred while linting /test/middleware.test.js
at detectJestVersion (/.eslint-tmp/node_modules/eslint-plugin-jest/lib/rules/utils/detectJestVersion.js:22:9)
at create (/.eslint-tmp/node_modules/eslint-plugin-jest/lib/rules/no-deprecated-functions.js:31:107)
at Object.create (/.eslint-tmp/node_modules/@typescript-eslint/utils/dist/eslint-utils/RuleCreator.js:39:20)
at createRuleListeners (/.eslint-tmp/node_modules/eslint/lib/linter/linter.js:1019:15)
at /.eslint-tmp/node_modules/eslint/lib/linter/linter.js:1151:7
at Array.forEach ()
at runRules (/.eslint-tmp/node_modules/eslint/lib/linter/linter.js:1085:31)
at #flatVerifyWithoutProcessors (/.eslint-tmp/node_modules/eslint/lib/linter/linter.js:2115:4)
at Linter._verifyWithFlatConfigArrayAndWithoutProcessors (/.eslint-tmp/node_modules/eslint/lib/linter/linter.js:2203:43)
at Linter._verifyWithFlatConfigArray (/.eslint-tmp/node_modules/eslint/lib/linter/linter.js:2306:15)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: e1ce5dd9-2773-47d0-89c6-6bff9218b109
📥 Commits

Reviewing files that changed from the base of the PR and between 93127dc and 3265e85.

📒 Files selected for processing: 7
  • .changeset/multipart-range-requests.md
  • .cspell.json
  • README.md
  • src/middleware.js
  • src/utils.js
  • test/middleware.test.js
  • types/utils.d.ts

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

Comment thread src/utils.js
@codecov

codecov Bot commented Oct 23, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.89%. Comparing base (93127dc) to head (6152bd1).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2496      +/-   ##
==========================================
+ Coverage   96.61%   96.89%   +0.28%     
==========================================
  Files          25       25              
  Lines        2657     2704      +47     
==========================================
+ Hits         2567     2620      +53     
+ Misses         90       84       -6     

☔ 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.

A multipart/byteranges body sends its first part before a later range is
read; when that read fails, there is no error page left to send. sendError
now destroys a response whose headers are out, and the stream error
handler destroys it when sending the page throws (as on fastify, which
does not report the headers as sent) instead of leaving the rejection
unhandled and the client waiting.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Caution

Some comments are outside the diff and can’t be posted inline due to GitHub limitations.

⚠️ Outside diff range comments (1)

🟡 Minor · Cap excessive multipart ranges. · middleware.js:1072

src/middleware.js:1072
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Cap excessive multipart ranges.

createMultipartByteranges opens ranges sequentially, so the request does not create one active file stream per range. However, range-parser does not limit range count, and each accepted range still adds filesystem-open and multipart-header overhead. A bounded request header can contain many disjoint single-byte ranges.

Add a range-count cap before creating the multipart body. For requests above the cap, use the existing regular-response path or reject the request. This is a minor availability risk for development middleware, not a major issue.


ℹ️ Review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 3fc5de2c-aa23-468d-8318-ddb5cf53a195
📥 Commits

Reviewing files that changed from the base of the PR and between 3265e85 and 21af39b.

📒 Files selected for processing: 2
  • src/middleware.js
  • test/middleware.test.js

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

Also drops the clean-up of a stream left by a strong ETag: it buffers
what it reads, so there is none.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA

Copy link
Copy Markdown
Member Author

@coderabbitai On the outside-diff Minor (cap the number of ranges): no change for now.

The overhead is bounded by the request header size. Node's default is 16 KB, which allows roughly 2,000 one-byte ranges, so about 200 KB of part headers in one response. Parts are read one at a time, so only one file stream is open at once.

A cap such as Apache's MaxRanges 200, falling back to the full 200 response above it, is a small follow-up if the maintainer wants it.


Generated by Claude Code

@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

@alexander-akait Understood. No range-count cap is needed for this PR in response to my minor suggestion. It can remain an optional follow-up.

Would you like me to open a follow-up issue to consider a cap and full 200 fallback?

You are interacting with an AI system.

As Apache's MaxRanges default: each range costs a read and a part header,
so a request for more is answered with the regular response instead of a
multipart body. Also documents the test helpers' callbacks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA

Copy link
Copy Markdown
Member Author

@coderabbitai The maintainer asked for the remaining items to be resolved, so 96ea65e adds:

  • Range cap (the outside-diff Minor): a request for more than 200 ranges (MAX_RANGES, Apache's MaxRanges default) now gets the regular 200 response with the whole file, plus a warning in the log. A test sends 201 disjoint ranges and gets the full file on every framework. The changeset mentions the cap.
  • Docstring coverage: JSDoc on the two test callbacks that lacked it (rawBody's parser and the failing createReadStream stand-in).

test/middleware.test.js passes 6705/6705, every changed statement in src/ is covered, and npm run lint passes.

No follow-up issue is needed.


Generated by Claude Code

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Caution

Some comments are outside the diff and can’t be posted inline due to GitHub limitations.

⚠️ Outside diff range comments (1)

🟡 Minor · Make the multipart callback input match the declared ReadStream type. · middleware.js:1165

src/middleware.js:1165
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Make the multipart callback input match the declared ReadStream type.

For a multipart response, src/middleware.js passes a plain Readable to modifyResponseData. The cast at line 1165 presents that value as Buffer | ReadStream, which hides the mismatch from the type checker. A callback that reads ReadStream-only fields, such as .path, can receive undefined on this path.

Do not fix this with the cast. Removing the cast alone causes a type error at this call. Either widen the declared callback data type to include Readable, or stop passing a plain Readable to this callback. Widening changes the public callback input type for typed consumers, so make that choice deliberately.


ℹ️ Review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 396124b8-28c6-43ae-bfd3-ea3d98b00603
📥 Commits

Reviewing files that changed from the base of the PR and between fcebf57 and 96ea65e.

📒 Files selected for processing: 3
  • .changeset/multipart-range-requests.md
  • src/middleware.js
  • test/middleware.test.js
🚧 Files skipped from review as they are similar to previous changes: 1
  • .changeset/multipart-range-requests.md

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

@alexander-akait I couldn't produce a complete response to this request. Please try again.

You are interacting with an AI system.

A multipart/byteranges body is a plain Readable, not a ReadStream, so the
callback's data, and the data it returns, are now typed Buffer | Readable
instead of being cast to Buffer | ReadStream. A ReadStream is still one.
Also replaces two inline callbacks in the new tests with loops.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA

Copy link
Copy Markdown
Member Author

@coderabbitai Addressed the outside-diff Minor on modifyResponseData in afe44d1. The cast is gone, and the public type now says what is passed: ModifyResponseData's data, and ResponseData.data, are Buffer | Readable.

A ReadStream is a Readable, so single-range and whole-file callers see no change in what they get. Callbacks written inline in the options are contextually typed and still compile. Only a callback declared separately, with its parameter annotated exactly Buffer | ReadStream, needs that annotation widened. The changeset and the README note both say this.

Also replaced the two remaining inline callbacks in the new tests with loops, for the docstring coverage warning. test/middleware.test.js and test/validation-options.test.js pass (6808/6808), and so do lint and types.


Generated by Claude Code

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to GitHub limitations.

⚠️ Outside diff range comments (2)

🟡 Minor · Count requested ranges before combining them. · middleware.js:1077

src/middleware.js:1077
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Count requested ranges before combining them.

parsedRanges.length counts merged ranges. For example, 201 identical requested ranges become one parsed range. This branch then sends a single-range 206 response instead of the promised full-file 200 response. Check the range count before parsing with combine: true, and retain the existing merge for accepted requests. (raw.githubusercontent.com)

🟡 Minor · Preserve request order when a range is contained. · middleware.js:1100

src/middleware.js:1100
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Preserve request order when a range is contained.

For bytes=100-200,400-500,0-300, range-parser v1.3.0 merges the first and third ranges but assigns the merged range the third range’s index. The multipart response therefore puts 400-500 before 0-300, although the merged range includes the first requested range. Order the merged ranges by their earliest matching requested range, and add this case to the multipart tests. (raw.githubusercontent.com)


ℹ️ Review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 93e09870-4feb-48fc-949a-b10875827d57
📥 Commits

Reviewing files that changed from the base of the PR and between 96ea65e and afe44d1.

📒 Files selected for processing: 6
  • .changeset/multipart-range-requests.md
  • README.md
  • src/index.js
  • src/middleware.js
  • test/middleware.test.js
  • types/index.d.ts
🚧 Files skipped from review as they are similar to previous changes: 1
  • README.md

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

Comment thread .changeset/multipart-range-requests.md Outdated
@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
git show --stat afe44d1
ast-grep outline src/index.js --match 'ResponseData|ModifyResponseData|Readable'
rg -n -C 4 'Buffer \| Readable|multipart|ReadStream|ModifyResponseData' src/index.js types/index.d.ts README.md .changeset/multipart-range-requests.md
git show afe44d1 -- test/middleware.test.js test/validation-options.test.js

Length of output: 13573


@alexander-akait I couldn't produce a complete response to this request. Please try again.

You are interacting with an AI system.

The 200-range cap now counts the ranges the header lists, not the ones
left after merging, and is applied when the header is read, so a strong
ETag never reads only a range that then goes out as the whole file.
Merged ranges are ordered by the first requested range each one holds:
range-parser gives a merged range the place of the last one merged in.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UjuMAuk9o6UazjHzcAQCTA

Copy link
Copy Markdown
Member Author

@coderabbitai Both outside-diff Minors are fixed in 6152bd1. I reproduced both with range-parser 1.3.0.

  • Count ranges before merging: confirmed. 201 copies of 0-9 merge into one range and got a single-range 206. The cap now counts the ranges the header lists, and it is applied where the header is read, in getRangeHeader. Placement matters: with a strong ETag, the ETag code reads the requested range before the range branch runs. A cap applied after that would have sent only that slice as the "whole file" 200. A test covers each case: basic, and strong ETag (same Content-Length and ETag as a plain GET).
  • Order when a range is contained: confirmed. bytes=100-200,400-500,0-300 came out as 400-500, 0-300. Merged ranges are now sorted by the first requested range each one holds, using a second, uncombined parse (memoized like the first). The sort uses toSorted, so the memoized array is never mutated. A test asserts 0-300, 400-500.

All three new tests fail on the previous commit and pass now. test/middleware.test.js and test/validation-options.test.js pass 6832/6832, every changed statement in src/ is covered, and npm run lint passes.


Generated by Claude Code

Copy link
Copy Markdown
Member Author

@coderabbitai review


Generated by Claude Code

@coderabbitai

coderabbitai Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
git show --format=fuller --stat 6152bd1
ast-grep outline src/middleware.js --match 'getRangeHeader|parseRange' --view expanded
ast-grep outline test/middleware.test.js --match 'range|Range' 
ast-grep outline test/validation-options.test.js --type function
git show 6152bd1 -- src/middleware.js test/middleware.test.js test/validation-options.test.js
rg -n -C 8 'MAX_RANGES|toSorted|getRangeHeader|combine: false|201|100-200,400-500,0-300' src/middleware.js test/middleware.test.js

Length of output: 18554


@alexander-akait I couldn't produce a complete response to this request. Please try again.

You are interacting with an AI system.

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.

Support for multipart range requests

1 participant