RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2]
Peyang
duke at openjdk.org
Thu Oct 30 10:25:35 UTC 2025
On Wed, 29 Oct 2025 17:40:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:
>> Thank you for your reviews.
>> I initially added `ETag` header for `If-Range` because I misunderstood it was a requirement, but it is actually not mandatory. So I will remove it from this patch.
>> If a follow-up ticket could be created, since I don’t have permissions, I’d be happy to take it on.
>> However, whether supporting ETag here is truly necessary is still open for discussion.
>
> Do we also need/want to support `If-Range`? The thing is that we can't guarantee that the file will not be modified (either externally or by other threads in the same VM) after having read the last modified date. How strong is the guarantee provided by `If-Range` supposed to be?
>
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-last-modified) seems to imply that `Last-Modified` only provides a weak guarantee - as it is documented as "the date and time at which the origin server believes the selected representation was last modified".
>
> Does the same apply for `If-Range`?
You are right that we cannot guarantee that the file won’t be modified after reading its attributes.
RFC 9110 defines `Last-Modified` as "the date and time at which the origin server believes the selected representation was last modified", so it only provides a weak guarantee.
Strict `If-Range` support would require a strong `ETag`.
Since we don’t have strong `ETag` support yet, we only provide a weak `Last-Modified`-based check, which is usually sufficient for resuming downloads.
Full `If-Range` support can be considered later if needed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477360821
More information about the net-dev
mailing list