Bug Second level .m3u or 302 redirect
#1
I've done extensive search on that matter, so excuse me if this problem was already discussed. I have the following problem:

For security purposes we are using unique URLs for each click. The URL contains a hash that is valid only for about a second and can be used only once. If the URL is opened, the hash is invalidated and can not be used again.

So far so good. My problem is that I can not make Simple (and Kodi for that matter) follow http redirects (302) or open second-level m3u playlist.

The main playlist is something like this:

#EXTM3U
#EXTINF:-1,Channel 1
http://some.com/generate-hash.php?channel=1
#EXTINF:-1,Channel 2
http://some.com/generate-hash.php?channel=2

The script generate-hash.php is pretty simple (for testing purposes). It contains only:

header("Content-type: audio/x-mpegurl");
print "#EXTM3U\n#EXTINF,-1,Live stream\nhttp://some.com/static-stream-for-test";

Unfortunately, this does not work. Kodi / Simple makes one HEAD request to http://some.com/generate-hash.php?channel=1, then one GET request to the same address and that's all - the link inside the second m3u list (http://some.com/static-stream-for-test) is never opened.

I have tried to trick Kodi / Simple to think the URL is an m3u playlist by adding an extension:

#EXTM3U
#EXTINF:-1,Channel 1
http://some.com/generate-hash.php?channel=1&ext=.m3u
#EXTINF:-1,Channel 2
http://some.com/generate-hash.php?channel=2&ext=.m3u8

but to no avail.

So I have modified the generate-hash.php to look like this:

header("Location: http://some.com/static-stream-for-test");

Now Kodi / Simple is generating 3 requests: HEAD request to http://some.com/generate-hash.php?channel=1, then after receiving the 302 answer - another HEAD request to http://some.com/static-stream-for-test, and a GET request to (!!!) http://some.com/generate-hash.php?channel=1 instead of http://some.com/static-stream-for-test

It looks like Simple (or Kodi) does not support second-level m3u's and does not support HTTP redirects either (although it DOES follow the 302 redirect on the HEAD phase, but not on the GET one).

BTW, the HEAD phase makes me nervous, as in real life it invalidates the hash, because the hash can be used one-time only and the streaming server does not support HEAD requests, translating them to GET. But that's another story. I will think about how to get rid of this unneeded HEAD request later.

So, does anyone knows a solution of my original problem - a unique, one-time-only URL, generated on-the-fly for each click on the channel?
Reply
#2
Well, after another 30 minutes of deep digging and sniffing, I found a partial solution (actually a workaround) of the "302 redirects not working" problem.

The reason for Location: header not working is the absence of Accept-Ranges: none

If the php script does not *explicitly* specify an Accept-Ranges: header, then Apache is adding Accept-Ranges: bytes

And the real bug in Kodi / Simple (or maybe the underlying python library) is that if the web server returns Accept-Ranges: bytes, the library most probably assumes that the next request should be GET with a range, ignoring the response code of 302 and the Location: header.

However, IT IS still a bug and should be fixed (wherever it is)
Reply
#3
Interesting. I will keep my eye on this. I also like to work witk top-level and second level m3u files because it is easier to maintain (even if at first it's a lot of work).
Reply



Logout Mark Read Team Forum Stats Members Help
Second level .m3u or 302 redirect0
This forum uses Lukasz Tkacz MyBB addons.