[gdal-dev] vsicurl configuration design decisions

[Sean Gillies]

Even, Craig,

On Thu, Oct 12, 2017 at 4:15 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Craig,
>
>
>
> > True, but that does eliminate ambiguity in the URL, and does so in a
>
> > well-known way.
>

I'd like to point out that very often URLs in a query string do not need to
be encoded. Both the Python (see my earlier example) and Node standard
parsers will handle the string

/viscurl?option1=foo&option2=bar&url=https://example.com/foo.tif

without any URL encoding.

> url.parse('/viscurl?option1=foo&option2=bar&url=
https://example.com/foo.tif', true)
Url {
  protocol: null,
  slashes: null,
  auth: null,
  host: null,
  port: null,
  hostname: null,
  hash: null,
  search: '?option1=foo&option2=bar&url=https://example.com/foo.tif',
  query:
   { option1: 'foo',
     option2: 'bar',
     url: 'https://example.com/foo.tif' },
  pathname: '/viscurl',
  path: '/viscurl?option1=foo&option2=bar&url=https://example.com/foo.tif',
  href: '/viscurl?option1=foo&option2=bar&url=https://example.com/foo.tif' }

If the web resource has a query string of its own, it will certainly have
to be encoded.

Typing URLs by hand into the console, URL-encoded or not, is always going
to invite mistakes. In my experience, we're more likely to be selecting and
copying from a UI element or the output of another program, and it would be
unfortunate to trade away the benefits of URL standards only to make typing
easier.

>
>
> > Does the current scheme use any encoding?
>
>
>
> No
>
>
>
> > How would you escape text in
>
> > option values that might use `=` and `,` etc? Or are there guaranteed to
> be
>
> > no freeform-text options in these paths?
>
>
>
> Currently, given the supported set of options and values, yes. In case of
> future ambiguity, yes, we'd need to define some escaping rules.
>

The web already has escaping rules built in, one of the benefits I alluded
to above.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171013/22ee1c90/attachment.html>