On Wed, 29 Oct 2025 17:40:44 GMT, Daniel Fuchs <[email protected]> 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
