On Fri, 31 Oct 2025 14:45:18 GMT, Daniel Fuchs <[email protected]> wrote:
>> I recall reading this part of the RFC before. >> Since it says *MAY*, and given that this is a simple web server, I wasn't >> sure if such validations are strictly required, >> so I didn't implement them. >> But if you think it's necessary, I can add them now. > > Yes please. I'd prefer to have built-in validation. I implemented a check that validates whether the ranges are in ascendnig order and non-overlapping, returning an error if they are not. However, I have some concerns: this restriction might be too strict. Instead of outright rejecting requests with overlapping or unsorted ranges, what if the server simply combines overlapping ranges and sorts them before returning? According to [RFC 7233 §15.3.7.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7.2-4): > When multiple ranges are requested, a server **MAY** coalesce any of the > ranges that overlap, or that are separated by a gap that is smaller than the > overhead of sending multiple parts, regardless of the order in which the > corresponding range-spec appeared in the received > [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header > field. In other words, rather than strictly validating and rejecting, we could treat this as an efficiency optimization on the server side. I think this approach would be more practical. I’d like to hear your thoughts on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2483528850
