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

Michael Sumner mdsumner at gmail.com
Fri Mar 27 12:36:35 PDT 2026


I'm concerned that it's an exception across the suite of other protocols
and that designing a consistent scheme for automatic swapping in would be a
lot of work.

What about https://.zip, or NETCDF:https://..nc:varname?  Some just
automatically work here after chain is unpicked? But also add vsizip?, what
about others?

But yes I'm generally supportive, I don't think an effort to raise
awareness of using GDAL protocols properly will succeed within the
onslaught of downstream interfaces.

Cheers, Mike

Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com

On Sat, Mar 28, 2026, 04:15 Kirk Waters - NOAA Federal via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Having made that mistake more than once, I would be in the happy camp.
>
> Kirk Waters, PhD
> NOAA Office for Coastal Management
> Applied Sciences Program
> coast.noaa.gov/digitalcoast
>
>
>
>
> On Fri, Mar 27, 2026 at 1:08 PM Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>> 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.
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260328/eef2da4d/attachment-0001.htm>


More information about the gdal-dev mailing list