-
Notifications
You must be signed in to change notification settings - Fork 15
test: range requests of deserialized files #213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Results against Kubo master: Summary
|
Results against Kubo latest: Summary
|
41e2a08
to
b7a423f
Compare
b7a423f
to
789cfac
Compare
makes test more representative of seeking inside of a partially available file
Results against Kubo fix/range-suffix: Summary
|
content-type is not hard requirement, and implementations may have easier or harder time with coming up with the right one. if the content type info is not part of DAG metadata, and needs to me sniffed (majority of content in 2025), then this internal sniffing may produce different results in different file x library permutations. in practice, it does not matter, browsers will stream videos just fine. lets focus on Content-Range and body being correct - if we need to test Content-Type, let's move it to a different test suite
f2719c6
to
ad744bc
Compare
ensure behavior described in ipfs/boxo#856 (comment) is covered by test
v0.8.0Changed |
Because this adds new tests that will start failing in Kubo until fix from ipfs/boxo#922 lands, I'm shipping this. as Let's continue in ipfs/boxo#922 |
This is WIP port of HTTP Range tests described in #154 (comment)
cannot detect content-type: failed to fetch all nodes
returned right now by boxo/gateway (or create better fixture that does not clash with content-type sniffing logic)Accept-Ranges: bytes
hint on non-range deserialized responseAims to close #154