Bug in HTTP Handler about osio HOT 3 CLOSED

Maybe an option in godal.RegisterVSIAdapter to prevent stripping the scheme would be a bit more generic?

from osio.

Maybe the best would be to always feed the scheme/protocol and let the underlying handler do the TrimPrefix if needs be?
I'd argue that the protocol (http/ https, ftp/ftps) is semantically fully part of the "key".

This would not break existing implementation as the scheme is systematically stripped if it exists (https://github.com/airbusgeo/osio/blob/main/uri.go#L19).

from osio.

In gdal world, the prefix is only used to register a handler, and is not part of the key (e.g., you use /vsicurl/https://server/path), so it is customary for gdal to drop this prefix when forwarding to the underlying handler. In our case we are using the prefix in both ways, thus the mixup we have here.
In theory, in order to not break backwards compatibility we should add a StripPrefix() option to godal.RegisterVSIAdapter that defaults to true. I believe that the use-case is sufficiently widespread that we can tolerate it defaulting to false, and make sure that all osio adapters gracefully handle the prefix://bucket/object and bucket/object keys ( which I believe it the case ). Are you willing to submit a PR to godal for this ?

from osio.