First of all, thanks for making this great service available.
Every IPFS UnixFS object has its total size and component blocks specified in a DAG document (or for single-block object smaller than 256KB, within a protocol buffer representation), guaranteeing both that the size is known ahead of time and that range requests should technically always be possible. The Cloudflare gateway currently seems to respond with
Transfer-Encoding: chunked for every file resource I’ve attempted to fetch, this includes both long (multi-block) and short (single block) files and when the response cache status is marked as a HIT, for example:
wget -S https://cloudflare-ipfs.com/ipfs/QmUbw27P1w1Q8Rejr9YB4aKCkHnDq1CxyVhsXvywoudoSq HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Thu, 20 Sep 2018 16:41:39 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Access-Control-Allow-Headers: Content-Range, X-Chunked-Output, X-Stream-Output Access-Control-Allow-Methods: GET Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Content-Range, X-Chunked-Output, X-Stream-Output Cache-Control: public, max-age=29030400, immutable Etag: W/"QmUbw27P1w1Q8Rejr9YB4aKCkHnDq1CxyVhsXvywoudoSq" Last-Modified: Thu, 20 Sep 2018 16:30:04 GMT Suborigin: ipfs000bciqf2ecguqktel77m6ogarh4bwkimtdkzr57my7cw7ke5qhph6v2a4q Vary: X-Ipfs-Secure-Gateway, Accept-Encoding X-Ipfs-Path: /ipfs/QmUbw27P1w1Q8Rejr9YB4aKCkHnDq1CxyVhsXvywoudoSq/ CF-Cache-Status: HIT Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Server: cloudflare
I’ve checked multiple other gateways (
www.eternum.io) and all respond with both
Accept-Ranges: bytes. The same for the standard local gateway created by
This seems unexpected. I would assume this a known issue / something that’s being worked on?
(Edits: some minor corrections after investigating deeper into the spec)