KML Layer utility decodes URL invalidating the file access

Anonymous User

Original User: erichcline

I have a KML files hosted in Windows Azure which provides an access url.

Example download URL provided by Azure: (expires)

https://atlasuserdata.blob.core.windows.net/erich-elaineintegralgis-onmicrosoft-com/hiking.kml?sv=2013-08-15&sr=b&sig=6ChtkDZig5Zwa75ECUPt/lNPKQKGLoh62+aE+8f8f0c=&st=2014-05-07T23:54:48Z&se=2014-05-08T00:59:48Z&sp=r

The KML Utility process decodes the URL and sig attribute which invalidates the Azure download.
URL

https://utility.arcgis.com/sharing/kml?url=https://atlasuserdata.blob.core.windows.net/erich-elaineintegralgis-onmicrosoft-com/hiking.kml?sv=2013-08-15&sr=b&sig=6ChtkDZig5Zwa75ECUPt/lNPKQKGLoh62+aE+8f8f0c=&st=2014-05-07T23:54:48Z&se=2014-05-08T00:59:48Z&sp=r&model=simple&folders=&outSR={"wkid":4326}&callback=dojo.io.script.jsonp_dojoIoScript2._jsonpCallback

the download url contains a sig attribute that Azure uses to authenticate the download.
encoded:  sig=6ChtkDZig5Zwa75ECUPt%2FlNPKQKGLoh62%2BaE%2B8f8f0c%3D
decoded:  sig=6ChtkDZig5Zwa75ECUPt/lNPKQKGLoh62+aE+8f8f0c=

This makes the publicly facing KML download fail.
Does anyone know a way around this?

MPCDesktop.jpg

MPCTabletOffset.jpg

DanielWalton

We encountered this same issue with Signed URL's from Amazon S3. The workaround we found was to keep generating a new URL (with a new signature string) until it contained no encoded plus signs (%2B), since those are likely being interpreted as spaces by the proxy.