[vlc-devel] [patch] [LUA HTTP] adding file:// to the Input field

[Erik Saule]

> > Luckily, it happens there is a function for doing that in
> > javascript. The attached patch use this function to generate a valid
> > MRL. I checked the behavior of the code in presence of spaces and
> > korean caracters.
> 
> Nice! However encodeURI() still leaves some characters encoded. For
> example, a file name containing # will cause an error. Also, this won't
> work properly on windows: backslashes will be encoded instead of being
> changed to slashes.

Oh. Actually, there are three functions in javascript that can be
usefull: encodeURI(), encodeURIcomponent() and escape(), they do not
all encode the same things. I did not like encodeURIcomponent because
it encodes the slashes. I never really did javascript before. Maybe
escape is the one we are looking for.

http://www.w3schools.com/jsref/jsref_encodeURIComponent.asp
http://www.w3schools.com/jsref/jsref_encodeURI.asp
http://www.w3schools.com/jsref/jsref_escape.asp

Maybe we should convert the \ into / then call escape ?

> But I'm not too sure whether it's the right place to fix this. There are
> a number "VLC remote" applications, and they rely on the server-side
> HTTP interface, independent of what the javascript we provide does.
> If the server stops accepting mere file paths in 1.2, won't it break
> all of these applications? Do we care?

I tried to match the "input" field with the behavior of the MRL field
in the default vlc interface in media -> advanced open file -> show
more option. The interface encodes the quotes, none english
characters, spaces, but also arobase. But that's more a hack than a
fix. I am not sure what the http interface expect so I assumed any
valid MRL should be valid as well.

> > Notice that some downstream javascript functions were messing with
> > quotes leading to the wrong MRL. I removed them.
> 
> Thanks for pointing that out. The issue was caused by a bug server-side
> preventing the unescaping of the quotes, so that's where I fixed it.
> Although the interest of escaping quotes and backslashes here is still
> dubious to me.

I am not sure there is a point in escaping quotes. The default vlc
interface actually transform quotes in %27.'