fix: reject multipart ranges before validation

[shblue21]

Motivation

ServeDir / ServeFile do not support multipart range responses, but they still validate multipart Range headers before later rejecting them with 416 Range Not Satisfiable.

That means requests that are guaranteed to be rejected still pay the cost of validate(file_size) first. In practice, this includes the pairwise overlap checks done during range validation.

Solution

Reject multipart ranges before calling validate(file_size).

This change keeps the fix small by only updating serve_dir/open_file.rs:

• parse the range header as before
• if more than one range is present, immediately return an error
• only call validate(file_size) for single-range requests

This reuses the existing Err(_) -> 416 response path and adds a regression test covering a valid multipart range request.

Note: this changes the 416 response body for valid multipart range requests from Cannot serve multipart range requests to empty, since they now fall through the existing generic Err(_) -> 416 path in future.rs.

Refs: #660

[jplatte]

Note: this changes the 416 response body for valid multipart range requests from Cannot serve multipart range requests to empty, since they now fall through the existing generic Err(_) -> 416 path in future.rs.

I think it would make sense to keep the specific error message body. Can you bring it back?

[shblue21]

Thanks. I’ll keep the multipart-specific body so the response stays behavior-preserving. That will require a small future.rs update, and I’ll keep the patch as minimal as possible.

[shblue21]

Added the small future.rs change. Multi-range requests still skip validate(file_size), and the regression test now checks the multipart-specific 416 body.

[jlizen]

@shblue21 do you see a reason not to support the behavior of flattening to single-part GET instead? Even if opt-in due to DOS risk (in which case your approach seems fine for rejection, though I have a small nit on internal error modeling).

IETF seems to prefer that,the RFC states:

A server MAY ignore the Range header field. However, origin servers
and intermediate caches ought to support byte ranges when possible,
since Range supports efficient recovery from partially failed
transfers and partial retrieval of large representations. A server
MUST ignore a Range header field received with a request method other
than GET.

Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability.

[jlizen]

This doesn't seem like quite the right error, this refers to overlapping ranges within a multipart request. Meanwhile we don't support them at all.

Can we have a local error type instead that more clearly denotes what's happening, if we preserve this behavior?