[gdal-dev] Ignore content-length in vsicurl?

Daniel Evans daniel.fred.evans at gmail.com
Tue Sep 10 06:57:10 PDT 2024


Hi all,

I am attempting to read a dataset via /vsicurl/ where I believe the server
is incorrectly returning `content-length: 0` in response to HEAD requests.
This causes GDAL to believe it's a zero-length file, and it therefore can't
be read.

If I download the file via HTTP GET, it's valid, and GDAL can read it
locally. I've also confirmed I can use /vsicurl/ on some test datasets in
the GDAL repo.

Is it possible to force GDAL to work around the faulty content-length
header, or is it too fundamental a problem to ignore?

I've separately got in touch with the data provider to see if they are able
to fix the issue at their end.

Cheers,
Daniel


URL of the troublesome dataset:
https://data.source.coop/earthgenome/sentinel2-temporal-mosaics/20NMH_2024-04-01_2024-08-01/B08.tif


Example HTTP header responses I'm seeing:

GET

HTTP/2 200
date: Tue, 10 Sep 2024 13:47:54 GMT
content-type: binary/octet-stream
content-length: 278198294
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
etag: "a79f3f685281d6681e4d362536c5b3eb-34"
last-modified: Thu, 25 Jul 2024 13:16:08 GMT
x-version: 0.0.16
access-control-allow-credentials: true

HEAD

HTTP/2 200
date: Tue, 10 Sep 2024 13:48:08 GMT
content-type: binary/octet-stream
content-length: 0
x-version: 0.0.16
access-control-allow-credentials: true
etag: "a79f3f685281d6681e4d362536c5b3eb-34"
last-modified: Thu, 25 Jul 2024 13:16:08 GMT
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240910/db9f9701/attachment.htm>


More information about the gdal-dev mailing list