Problem when opening file over HTTP

[kdl]

Hello dear VideoLAN Community,

I wanted to test opening an Videofile (.mkv) over HTTP, which worked perfectly well, aside from a minor issue.
The URL looks like the following: /stream=guid=<a random guid>, without a file extension like .mkv.
This file opened via this link is returned by a web server as a physical file with the mimetype "video/x-matroska".
Playback starts normally, with a popup on my iPad "Unidentified Codec - VLC could not identify the audio or video codec".

After that popup, the video plays perfectly fine with video and audio working.

However, when pressing subtitles, it shows me subtitle tracks, but when I want to select them, I get the popup again, and it does not select the subtitle.
I'd like to be able to select a subtitle, and apparently I doubt the popup's correctness, when both video and audio works, and it even shows me all available subtitles.

Device: iPad Pro 9.7", iOS 11.1.2.

Would be nice if this can get sorted out, I yet have to test other mkv files served via this method in order to completely verify this behavior.
On pc, this streaming "setup" works fine with mpv.

Thanks in advance

[InTheWings]

that just means that those subtitles are not supported

[kdl]

First of all, thanks for your quick reply

For testing, I've let the file to be streamed download first, then opened it in VLC by appending ".mkv". The popup does not appear, and the subtitle works.
I suppose it comes down to the missing file extension when served over the webserver directly, however, I cannot verify that because I cannot open a file w/o a recognized file extension over a different app (DS File in my case) in VLC for iOS.

Is this something that can be fixed/improved?

[InTheWings]

are you sure you don't have a subtitiles files next to the mkv ? with same name

[kdl]

100%. I've only opened the same MKV via the same link directly via safari, proceeded to save it onto the iPad into a File Manager, renamed the file, and "Open in.." VLC for iOS.

Update:
tested if changing the URL might have an effect, but the problem remains. Tested with /stream.mkv?guid=<guid> and combined with /stream.mkv?guid=<guid>.mkv

Update2:
tested various methods to retrieve the stream from the Webserver. Both methods support range requests. Also tested a different file - the problem remains.