Developers

[squirreltown]

http://192.168.100.16:5000//webapi/entry.cgi?api=SYNO.FileStation.Download&version=2&method=download&path=/video/2010.jpg&mode=open&sid=e3kYlfOEenT8A14B0MNN453413

This is a request to a Synology NAS. They have just updated their firmware. Yuck.

This URL produces the proper thing - a thumbnail .jpg -if pasted into a browser. The Roku doesn't like it: *** ERROR: Invalid path:
I have tried escaping it but same results.

Thanks

[RokuMarkn]

Is that single quote supposed to be at the end?

--Mark

[squirreltown]

"RokuMarkn" wrote:
Is that single quote supposed to be at the end?

--Mark

Nope, sorry about that. (fixed)

[belltown]

Should that second double slash be a single slash?

And I think you need to escape your last two slashes to %2F

http://192.168.100.16:5000/webapi/entry.cgi?api=SYNO.FileStation.Download&version=2&method=download&path=%2Fvideo%2F2010.jpg&mode=open&sid=e3kYlfOEenT8A14B0MNN453413

[squirreltown]

"belltown" wrote:
Should that second double slash be a single slash?

And I think you need to escape your last two slashes to %2F

http://192.168.100.16:5000/webapi/entry.cgi?api=SYNO.FileStation.Download&version=2&method=download&path=%2Fvideo%2F2010.jpg&mode=open&sid=e3kYlfOEenT8A14B0MNN453413

Well that didn't change anything on the Roku.

In the browser it works with a double slash or a single slash (!), and the path part works without escaping the slashes. Not understanding this.

[EnTerr]

"belltown" wrote:
And I think you need to escape your last two slashes to %2F

Not necessarily because as а "reserved character", only in certain contexts `/` must be encoded to avoid confusion from "reserved purpose" use - and it has no "reserved purpose" in a query string.

"https wrote:
In the "query" component of a URI (the part after a ? character), for example, "/" is still considered a reserved character but it normally has no reserved purpose, unless a particular URI scheme says otherwise. The character does not need to be percent-encoded when it has no reserved purpose.

But you are right it was worth trying the other way, because "URI consumers shouldn't treat [them] differently ... but some do."

"squirreltown" wrote:
Well that didn't change anything on the Roku.
In the browser it works with a double slash or a single slash (!), and the path part works without escaping the slashes. Not understanding this.

How about if you open it in "incognito"/"private" browser window - does it work outright or does it force you to login first? If the latter, means it worked for you in the browser because you had previous session opened and it sends some cookies with each request.

[RokuMarkn]

Which method produces the "invalid path" error? Can you post some code? I've not been able to reproduce this using roUrlTransfer with your URL.

--Mark

[EnTerr]

@squirreltown - see https://global.download.synology.com/do ... _Guide.pdf

"Making Requests" wrote:

...

• _sid: Authorized session ID. Each API request should pass it, which is retrieved from the response of /webapi/auth.cgi, via either HTTP/HTTPS GET/POST method with “_sid” argument. Otherwise, if you pass it within “id” value of cookie of HTTP/HTTPS header, this parameter can be ignored.

I bet you are missing "Step 2: Log in" from the "API Workflow". URL works in browser because of cookies but for Roku you'll have to "explicitate" the SID.

[squirreltown]

"EnTerr" wrote:
@squirreltown - see https://global.download.synology.com/do ... _Guide.pdf

"Making Requests" wrote:

...

• _sid: Authorized session ID. Each API request should pass it, which is retrieved from the response of /webapi/auth.cgi, via either HTTP/HTTPS GET/POST method with “_sid” argument. Otherwise, if you pass it within “id” value of cookie of HTTP/HTTPS header, this parameter can be ignored.

I bet you are missing "Step 2: Log in" from the "API Workflow". URL works in browser because of cookies but for Roku you'll have to "explicitate" the SID.

Actually i am doing the log-in and using it. First you do the Auth, and you get a session id. then you attach that to every request. So next i get the list of files and that is fine. If you look at my first post, you'll see it.
Synology changed their firmware so that the Sharing API (which i was using because i can't figure out how to find the box on the LAN with a socket or however actual media players do it) doesn't actually send the files anymore, that seems to be done with a new Download API which was going fine until this problem. Unable to get past this, i tried setting up the web server and getting the files that way (no auth needed) and now the Roku won't play certain audio files that are known to be good (file plays fine every way except Roku, and Roku has played the file previously) so it skips the file and blows up the audio indexing. Just a snowball that keeps rolling.

"RokuMarkn" wrote:
Which method produces the "invalid path" error? Can you post some code? I've not been able to reproduce this using roUrlTransfer with your URL.

Mark, with the authorization requirement, I don't see how you can duplicate my setup without a Synology NAS on 6.0. I was sort of hoping for some obvious url error I wasn't seeing.

[belltown]

Are you using roUrlTransfer or HD/SDPosterUrl, etc?