HTTP Get with Authentication for VLC Viewer Web API

[Omar_Mussa]

I'm trying to connect to VLC Media Player app (v 3.0.4 : https://www.videolan.org/vlc/download-windows.html) via its http (Web) interface.

I've enabled the Web interface and set the Lua password to "test" per this page: https://www.howtogeek.com/117261/how-to-activate-vlcs-web-interface-control-vlc-from-a-browser-use-a...

I'm able to connect from a web browser by entering my user name as "" and password "test" and I get an expected XML response from this URL:

http://localhost:8080/requests/status.xml

(response status = 200 and resulting data is an xml string)

This request uses "Authorization: Basic"

When I do the same thing from LabVIEW (including authentication added to the headers manually per other posts, I get an error 404.  When I try to hit the same endpoint but without authorization from a browser I get error 401.  So I'm unclear as to what I'm doing wrong but it seems like something is not working.

Am using LabVIEW 2016 for this code (attached what I've tried).  I'm using password 'test' which is base 64 encoded from user:pwd to "OnRlc3Q=".

Not sure what else to try - I've tried setting the password at the 'OpenHandle' method but that didn't change anything. Have tried a bunch of other things after testing the endpoint API via Postman but nothing has gotten me out of error 404.

[Omar_Mussa]

I spent forever trying to get that to work and finally gave up.  I spent 5 minutes searching harder for a .NET example on the forums and and found one and modified it to add the headers and it works now.  Attached the VI with basic authentication headers set.  Would appreciate if someone from NI would try to figure out why the authentication headers fail in the LabVIEW HTTP GET but work in the .NET code attached here.  But at least I have a path forward.

[MilanR · Accepted solution]

On my machine LabVIEW Web Services is using port 8080. When I run the VLC Status Request VI I can see that LabVIEW Web Services are responding with a 404 by looking at the response headers, ie the header "Server: Embedthis-http" is included.

When I launch VLC with a different port https://wiki.videolan.org/documentation:modules/http_intf/#VLC_2.0.0_and_later

And modify the VLC Status Request VI to use a different port then the request seems to come from VLC (xml data about what is currently playing).

To see what vlc.exe is doing with port 8080 I ran netstat -a -b from an elevated command prompt and saw the following:

...

TCP 0.0.0.0:8080 mycomputername:0 LISTENING
[ApplicationWebServer.exe]

...

TCP [::]:8080 mycomputername:0 LISTENING
[vlc.exe]

...

From that it looks like LabVIEW Web Services are running on the ipv4 localhost on port 8080 and the VLC Server was running on the ipv6 localhost on port 8080. And indeed when using Chrome Developer Tools on the network tab you can look at one of the requests and see that the Remote Address for the requests are an ipv6 "[::1]:8080".

[Mark_Yedinak]

---

@MilanR wrote:

On my machine LabVIEW Web Services is using port 8080. When I run the VLC Status Request VI I can see that LabVIEW Web Services are responding with a 404 by looking at the response headers, ie the header "Server: Embedthis-http" is included.

When I launch VLC with a different port https://wiki.videolan.org/documentation:modules/http_intf/#VLC_2.0.0_and_later

And modify the VLC Status Request VI to use a different port then the request seems to come from VLC (xml data about what is currently playing).

To see what vlc.exe is doing with port 8080 I ran netstat -a -b from an elevated command prompt and saw the following:

...

TCP 0.0.0.0:8080 mycomputername:0 LISTENING
[ApplicationWebServer.exe]

...

TCP [::]:8080 mycomputername:0 LISTENING
[vlc.exe]

...

From that it looks like LabVIEW Web Services are running on the ipv4 localhost on port 8080 and the VLC Server was running on the ipv6 localhost on port 8080. And indeed when using Chrome Developer Tools on the network tab you can look at one of the requests and see that the Remote Address for the requests are an ipv6 "[::1]:8080".

---

And this brings up the topic of when will NI add IPv6 support to LabVIEW?

[Omar_Mussa]

Thanks @MilanR - I was pulling my hair out and now I know why!  I'll stick with my .NET solution now that I've done it since it works and is easy to read.

Thanks again!

Omar

[Omar_Mussa]

Disabling the NI LabVIEW Web Services solved the issue.