M3U file with HTTP links fails due to a bug in VLC GET request

I'm using nightly build VLC-Android-2.1.0-20170204-0235-ARMv7.apk on Android 6.0.1 (32 bit).

When a local (or network) M3U file is opened in VLC the HTTP links in that playlist (ts streams) return error 404, due to a bug in VLC GET request. Here is how VLC sends a request:

GET http://server.com:8888/file.php?query1=1&query2=ABC HTTP/1.1
Host: server.com:8888
Accept: */*
Accept-Language: en_US
User-Agent: VLC/3.0.0-git LibVLC/3.0.0-git
Range: bytes=0-

This request causes a server error 404, because the GET line should not include the "http://server.com:8888" part. Here is how the correct request should look like:

GET /file.php?query1=1&query2=ABC HTTP/1.1
Host: server.com:8888
Accept: */*
Accept-Language: en_US
User-Agent: VLC/3.0.0-git LibVLC/3.0.0-git
Range: bytes=0-

I investigated this bug by using a proxy on a PC where the GET line was auto-corrected by the proxy and VLC (Android) started the video stream just fine.

This is related to the core, not really Android codebase.

Can you share the M3U?

assigned to @Courmisch

changed milestone to %Bugs paradize

That's either 2.0 codebase or using adaptive-use-access as the adaptive stack does not send listed headers.

Desktop version of VLC v2.2.4 (Mac) works fine with the same M3U playlist. Only the Android version has this problem (tested 2.0.6 release and nightly build VLC-Android-2.1.0-20170204-0235-ARMv7.apk).

I will try to create a simple M3U file that reproduces the problem.

On desktop, you need to test 3.0, not 2.2.4

PEBKAC.

added Status::works for me label

closed

Passing the protocol and authority in the Request-URI is required if a proxy is configured (and AFAIK, it is permitted albeit optional in the absence of proxy).

VLC uses it iff a proxy is configured. Nothing to see here.

Indeed, when using proxy, absoluteURI is required in GET request (RFC 2616 - 5.1.2). Desktop version of VLC also sends full URL with proxy. My apologies for the wrong conclusion.

However, I just want to find why VLC 2.1 (Android) only works through proxy and causes 404 error with a direct connection (Desktop VLC 2.2.4 works with and without proxy, but latest nightly vlc-3.0.0-20170129-0336-git.dmg fails as well). It turns out that VLC 3.0.0 builds (Android and Mac) make two connections for the same HTTP link, which most probably triggers security of server (it refuses two connections). It looks that proxy just delays the second request.

The first request is successful, but the second one fails. Network sniffer shows these two requests:

GET /file HTTP/1.1
Host: server.com:8888
Accept: */*
Accept-Language: en_US
User-Agent: VLC/3.0.0-git LibVLC/3.0.0-git
Range: bytes=0-

HTTP/1.0 200 OK
Content-type: application/octet-stream
Connection: close
Cache-Control: no-cache
-----
->A little data sent
-----


GET /file HTTP/1.0
Host: server.com:8888
User-Agent: VLC/3.0.0-git LibVLC/3.0.0-git
Icy-MetaData: 1

HTTP/1.1 404 Not Found
Content-type: application/octet-stream
Connection: close
Cache-Control: no-cache

VLC 2.2.4 (Mac) which works fine, makes a single request:

GET /file HTTP/1.1
Host: server.com:8888
User-Agent: VLC/2.2.4 LibVLC/2.2.4
Range: bytes=0-
Connection: close
Icy-MetaData: 1

Currently, I can't share the M3U playlist since it may be locked by the IPTV provider.

Why does it fall back to HTTP/1.0 then?

Also, this proves it's not Android related, if you can reproduce with a nightly build.

The problem seems to be in all v3.0.0 builds. Current stable Mac v2.2.4 works fine, but the nightly vlc-3.0.0-20170129-0336-git.dmg fails the same way as Android nightly (VLC-Android-2.1.0-20170204-0235-ARMv7.apk). We may ignore the proxy side-effect and concentrate on why VLC now makes two connections for HTTP streams instead of one.

Some servers allow only one stream connection and when a second connection is made they return 404 or 500 error.

Should I open a new bug report or this can be moved to the core thread?

Don't bother opening a new bug if you can neither produce VLC logs and packet capture, nor a sample URL.

Besides, it looks like a server-side bug anyway.