geotiff.js
geotiff.js copied to clipboard
error loading COG with response status 200 instead of 206
This section of fetch() in source.js starting at line 188 (https://github.com/GeoTIFF/geotiff.js/blob/e2bab6c150035ac277aaedc4efb928813d0e06a3/src/source.js#L188) assumes that response.offset is equal to the requested offset (group[0] * this.blockSize), but that is only true if the fetch returned 206 with the requested range rather than 200 and the entire file (in which case response.offset is 0).
for (let i = 0; i < group.length; ++i) { const id = group[i]; this.blockRequests.set(id, (async () => { const response = await request; const o = i * this.blockSize; const t = Math.min(o + this.blockSize, response.data.byteLength); const data = response.data.slice(o, t); this.blockRequests.delete(id); this.blocks.set(id, { data, offset: response.offset + o, length: data.byteLength, top: response.offset + t, }); })()); }
The fix (untested) is: const o = id * this.blockSize - response.offset;
The bug is exhibited as a RangeError when loading from an object URL created from a File in Firefox on a Mac, but would also happen on any server that (legally) ignored a range request.
Hi @jcphill
Thanks for reporting that! This is actually a rather problematic topic, as TIFF files have the tendency to be rather large and more often than not not actually fitting in memory and it is likely better to not actually accept 200 responses but aborting the request instead.
There is, however, an extensive rework of the whole sources in the works: #94
I think such responses are handled better there. Maybe you can try that branch?
Thank you for your reply.
The logic is correct in the pull request at https://github.com/geotiffjs/geotiff.js/blob/dd72ff1a106e7113b6626a9e54f00987893357b8/src/source/blockedsource.js#L190
I'm glad to see that there is an allowFullFile option in the pull request to accept 200 responses.