opencontainers
`Cotent-Range` and `Range` syntax expected by this spec deviates from RFC 7233 (HTTP/1.1 Range Requests)
In the OCI spec, the Content-Range header is specified as:
Content-Range: <range>
where <range> must match the pattern ^[0-9]+-[0-9]+$ (e.g., "0-1023").
However, RFC 7233 (https://datatracker.ietf.org/doc/html/rfc7233) defines the Content-Range header syntax as:
Content-Range: <unit> <range-resp>/<size>
For byte ranges, this could be:
Content-Range: bytes 0-1023/2048
or
Content-Range: bytes 0-1023/*
This OCI spec omits both:
- The unit specifier ("bytes") and
- The total size or "*" after the slash
This inconsistency causes interoperability issues with HTTP libraries and proxies that strictly validate header formats according to RFC specifications. For example, Rust's https://crates.io/crates/headers crate.
The same applies to the Range header. Although the Range header uses slightly different syntax. Also see the syntax block in:
- https://developer.mozilla.org/de/docs/Web/HTTP/Reference/Headers/Content-Range
- https://developer.mozilla.org/de/docs/Web/HTTP/Reference/Headers/Range
This spec should either:
- Make explicit that it uses the standard HTTP headers with non-conforming syntax requirement, where custom validation and parsing must be implemented or
- Use a new oci-dsitribution spec specific header name to which the current requirements can be applied or
- Update the spec to require HTTP RFC compliant values (and update the conformance tests with it)
This spec should either:
- Make explicit that it uses the standard HTTP headers with non-conforming syntax requirement, where custom validation and parsing must be implemented or
I believe the spec makes it clear how the range headers are used. Is there wording you want to add to make this more explicit?
Use a new oci-dsitribution spec specific header name to which the current requirements can be applied or
Update the spec to require HTTP RFC compliant values (and update the conformance tests with it)
I don't think either of these are options we can consider. There are existing clients and servers that would be broken if we did either option. Doing either would require a major version change, so I can add it to the 2.x milestone, but doubt we'll see progress there any time soon.
