@czukowski said:
@coder-alpha
I’m still not convinced encoded headers are the real issue. Encoding is just a way of transmitting data. The program that reads it (Plex client in our case) may either send it to the target server as is or decode it. The XML generated from my channel also has Referer header urlencoded. Also note that the string also has XML entities encoded (&). Maybe trying to see what does the client really send to the server, perhaps using Wireshark, could shed some more light.
Out of curiosity, I’ve tried requesting URLs from both our channels with and without encoding of Referer header and I’ve got the same results in both cases. So whether it works or not, it appears that HTTP server doesn’t complain about the encoding either way.
Trying mcloud URL from your post with urlencoded Referer:
If you don’t mind can you try the .m3u8 stream from this page. The stream expires so would return a 403. When its still live it returns 200 but its content-length is 0.
Ok, so apparently I was wrong about servers not caring about urlencoding in Referer. But still, the question remains, does the Plex client even send the headers that it reads from the XML, or does it send it in ‘bad format’?
$ curl "http://2ey0dk.mcloud.to/1/8JDTfMRg1-8WCHKH8MAZ6g/0/c/j/c/rl6j4p/list.m3u8?e=1510830000" -H "Referer: http://mcloud.to" -I
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 16 Nov 2017 10:05:15 GMT
Content-Type: application/vnd.apple.mpegurl
Connection: keep-alive
Access-Control-Allow-Origin: *
X-Cache: HIT
$ curl "http://2ey0dk.mcloud.to/1/8JDTfMRg1-8WCHKH8MAZ6g/0/c/j/c/rl6j4p/list.m3u8?e=1510830000" -I
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 16 Nov 2017 10:06:24 GMT
Content-Type: application/vnd.apple.mpegurl
Content-Length: 0
Connection: keep-alive
@czukowski said:
Ok, so apparently I was wrong about servers not caring about urlencoding in Referer. But still, the question remains, does the Plex client even send the headers that it reads from the XML, or does it send it in ‘bad format’?
Thanks for confirming and yes it does seem to be partly a client issue as well. I dug up an old issue with the google drive service and found some relevant info quoted below. The info is from last year so the clients may have changed how they do things, so will try out on Android and see if I can get anywhere.
sander1:
I checked if maybe http_headers={‘Cookie’: ‘…’} would work, but this method has the same problem. I only have access to a limited number of devices that have a Plex client, but I’ll start the list below:
Clients that percent encode the http header/cookie value (and where video playback fails for this reason):
Plex/Web
Plex Media Player
Clients where video playback works fine because http header/cookie value is not percent encode:
iOS
Android (TV)
