#56 introduced request-response tests for IPIP-402, including entity-bytes
for range requests that return a minimal subset of blocks for passed byte range:
Request().
Path("/ipfs/{{cid}}", subdirWithMixedBlockFiles.MustGetCidWithCodec(0x70, "subdir", "multiblock.txt")).
Query("format", "car").
Query("dag-scope", "entity").
Query("entity-bytes", "512:1023"),
Tests included in #56 will confirm the response includes the correct subset of blocks for the file.
Extra mile for testing entity-bytes
Because fixture includes all blocks available for multiblock.txt
file, the compliance test will not detect when a backend is broken and downloads the entire thing from the beginning (0:1023
) just to return a slice of that (512:1023
).
Such implementation will produce a valid response for cached data, but cache misses will be excruciatingly slow, and usually timeout.
If the file is 4GiB video and the client requested 1MiB in the middle, nothing will happen for a long long time, because the backend will be busy retrieving 2GiB of data just to return the last 1MiB.
I believe conformance suite should be testing this, because if our internal teams ended up with this footgun in Rhea/Saturn (brainstorming fix in filecoin-saturn/L1-node#415), we most likely will see more of this in the future.
How to test this
We should have additional test with partially-resolvable-1GiB-multiblock.bin
, where only root block + child block responsible for requested range are present in the CAR fixture.
This way, the test will hang/timeout when an incorrectly implemented backend tries to fetch blocks that are not related to the entity-bytes
request.