Even, Craig, On Thu, Oct 12, 2017 at 4:15 PM, Even Rouault <even.roua...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev