[gdal-dev] Anyone has already forgotten the /vsicurl/ prefix?

[Even Rouault]

Hi,

Following-up on this, after a bit of not super conclusive 
experimentation, I gave up on the idea of a GDAL autoselection of HTTP 
driver vs /vsicurl/ . The sad reality is that the web in 2026 is not yet 
ready for GDAL very demanding expectations, i.e. that servers in the 
wild would return reliably & fastly a "Accept-range: none" or 
"Accept-range: bytes" header to a HEAD request.

So I've fallen back to documenting that whole issue in 
https://github.com/OSGeo/gdal/pull/14291

Even

Le 27/03/2026 à 18:08, Even Rouault via gdal-dev a écrit :
> Hi,
>
> I suspect that almost every GDAL user, even the most experienced, has 
> made the mistake of typing "gdalinfo https://example.com/my.tif" 
> instead of "gdalinfo /vsicurl/https://example.com/my.tif". Both 
> commands work, but the first one triggers the HTTP pseudo-driver which 
> downloads the entire file into memory before passing it to the GeoTIFF 
> driver, while the second reads it in chunks.
>
> I would be inclined to modify the GDALOpen() logic with the following 
> tweak: if the passed filename starts with "http://" or "https://", 
> automatically prepend "/vsicurl/", unless the string has query 
> parameters. That restriction about not having query parameters is 
> because in most of the cases this is for dynamically generated 
> resources that don't support range requests.
>
> For users really wanting to go through the HTTP pseudo-driver, we'd 
> modify it to accept a "HTTP:" prefix before the URL or it would 
> trigger if using the "-if HTTP" argument of command line utilities (or 
> allowed_drivers = ["HTTP"] in the API)
>
> So this change wouldn't be fully backwards compatible, but I feel it 
> would still make more people happy than unhappy.
>
> Thoughts?
>
> Even
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.