Context
Both snapshot viewers expose archive downloads as /:chainId/:snapshotName. The chain ID is used by latest.txt and manifest lookup, but the archive handlers pass only snapshotName to R2:
Reproduction
Using the current Tempo mainnet archive name from /4217/latest.txt:
tempo-4217-36317806-1787601702.tar.lz4
I sent Range: bytes=0-15 requests through three chain-scoped URLs to avoid downloading the archive:
/4217/<snapshot> -> 206, ETag "172d06ae659037b818897abfd444decf-80"
/42431/<snapshot> -> 206, same ETag and Content-Range
/999999/<snapshot> -> 206, same ETag and Content-Range
All three responses also returned the same 16-byte SHA-256 digest. I reproduced this against https://snapshots.tempo.xyz; the Reth viewer has the same routing pattern in code, but I did not make a production behavior claim for it.
Scope question
Is the chainId segment intended to scope an archive download to the selected network, or is it deliberately a compatibility/display-only segment for root-level legacy objects?
If it should enforce scope, I can put together a narrow follow-up with tests for matching, mismatched, and unknown chain IDs while preserving Range and conditional request behavior. If the current behavior is intentional, documenting that contract may be the better outcome. I have not opened a code change because rejecting mismatched paths could break existing download URLs.
Context
Both snapshot viewers expose archive downloads as
/:chainId/:snapshotName. The chain ID is used bylatest.txtand manifest lookup, but the archive handlers pass onlysnapshotNameto R2:Reproduction
Using the current Tempo mainnet archive name from
/4217/latest.txt:I sent
Range: bytes=0-15requests through three chain-scoped URLs to avoid downloading the archive:All three responses also returned the same 16-byte SHA-256 digest. I reproduced this against
https://snapshots.tempo.xyz; the Reth viewer has the same routing pattern in code, but I did not make a production behavior claim for it.Scope question
Is the
chainIdsegment intended to scope an archive download to the selected network, or is it deliberately a compatibility/display-only segment for root-level legacy objects?If it should enforce scope, I can put together a narrow follow-up with tests for matching, mismatched, and unknown chain IDs while preserving Range and conditional request behavior. If the current behavior is intentional, documenting that contract may be the better outcome. I have not opened a code change because rejecting mismatched paths could break existing download URLs.