Forbid reading an empty range in file serving handles

[eddyashton]

Sparked by a potential underflow mentioned in a comment here: #7643 (comment)

I view this is a change from exclusive to inclusive range-ends. With exclusive, you can spell the empty range, but with inclusive you can't. Most attempts to do so will hit a different kind of parsing error (you need to specify the range => you try to spell an invalid one), but you could hit this path for an empty file.

### Exclusive
# Single byte from a 1-byte file
Content-Range: bytes 0-1 / 1

# No bytes from a 1-byte file
Content-Range: bytes 0-0 / 1

# No bytes from a 0-byte file
Content-Range: bytes 0-0 / 0


### Inclusive
# Single byte from a 1-byte file
Content-Range: bytes 0-0 / 1

# Single byte from a 0-byte file!! Error!!!
Content-Range: bytes 0-0 / 0

# No bytes?? But in practice, an earlier parsing error
Content-Range: bytes 4-3 / 10

[Copilot]

Pull request overview

This PR tightens HTTP Range handling in the file-serving RPC endpoints (snapshot/ledger chunk download) to prevent attempts to read an empty byte range, avoiding underflow-style edge cases highlighted in #7643.

Changes:

• Reject requests whose computed range length is 0, returning a 400 with an “empty range” error.
• Extend snapshot range e2e coverage to include an additional open-ended range case and assert the new empty-range rejection.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/node/rpc/file_serving_handlers.h	Adds a guard to reject zero-length ranges before reading/constructing Content-Range.
tests/e2e_operations.py	Adds e2e cases to validate open-ended range behavior and the new “empty range” error path.

Comments suppressed due to low confidence (1)

tests/e2e_operations.py:428

• The added invalid-range case exercises the new empty-range rejection for start > end, but the original motivation mentions the edge case of an empty file (eg Content-Range: bytes 0-0/0). There isn’t currently a test that hits the 0-byte file path, so a regression in that specific scenario could slip through. Consider adding an e2e or lower-level test that serves a known empty file and asserts the chosen behavior (error vs empty 200/206 response).

                ("-1-5", "Invalid format"),
                ("-", "Invalid range"),
                ("-foo", "Unable to parse end of range offset value foo"),
                ("", "Invalid format"),
                (f"{a}-{a-1}", "empty range"),
            ]:
                r = do_request("GET", path, headers={"range": f"bytes={invalid_range}"})
                assert r.status_code == http.HTTPStatus.BAD_REQUEST.value, r
                assert err_msg in r.body.json()["error"]["message"], r