Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK (Read 2091 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

I've just noticed that trying to play BBC local radio Shoutcast streams results in a Bad Request 400 response in v1.4.1 and 1.4.2, but it works fine in v1.3.2:

http://open.live.bbc.co.uk/mediaselector/5/select/mediaset/http-icy-mp3-a/format/pls/proto/http/vpid/bbc_radio_manchester.pls
http://open.live.bbc.co.uk/mediaselector/5/select/mediaset/http-icy-mp3-a/format/pls/proto/http/vpid/bbc_radio_northampton.pls

These playlist files contains two streams (a main and reserve); each gets some session tokens appended in the PLS but the stream URLs also work without them.

I downloaded a PLS to test (Radio Northampton) and it contains URLs which look like this:

http://bbcmedia.ic.llnwd.net/stream/bbcmedia_lrmanc_mf_p?s=1550832369&e=1550846769&h=ee60b2466095db799f139700a7ba8cea
http://bbcmedia.ic.llnwd.net/stream/bbcmedia_lrmanc_mf_q?s=1550832369&e=1550846769&h=a168795779d457ceda0f23fa7cc4477b

The actual stream URLs are http://bbcmedia.ic.llnwd.net/stream/bbcmedia_lrnthhnts_mf_p (or http://bbcmedia.ic.llnwd.net/stream/bbcmedia_lrnthhnts_mf_q).

In v1.3.2, adding either of these to fb2k playlist works OK and double clicking starts playback. I can close the client, reopen and play again, works great. Old entries for other stations also work fine.

However in 1.4.1 and 1.4.2, I always get a 400 response. Opening and parsing the .pls URL works in both clients.

I can't see anything more in the console other than the 400 error when fb2k tries to open the URL. I believe these streams are not geofenced to the UK so you should be able to load and test.

I'll do a Wireshark today and see if the clients are talking differently to the Shoutcast server.
Don't forget International Talk Like A Pirate Day! September the 19th!

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #1
For me all your links work in 1.4.2

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #2
I guess you may not be using a proxy, I am. Sorry, forgot to mention this small but important detail!

In both clients, I'm inheriting browser proxy settings, and in turn the browsers use a PAC. We have various proxy servers, some intended for proxying traffic for specific domains. In this case, an Apache webproxy listening on port 81 is being correctly selected by fb2k.

The only difference I can see from Wireshark is in the headers:

fb2k v1.4.2 sends "User-Agent: foobar2000/1.x"
fb2k v1.3.2 sends "User-Agent: foobar2000/1.3.20"

Perhaps Apache webproxy refuses to accept "1.x" as a valid header? Not sure, would be slightly unreasonable if so. I can't see anything else obviously wrong but I can't see exactly how fb2k v1.4.2 is trying to handshake the connection as I don't control our corporate proxies.

If I directly specify the same proxy server (in Networking -> Proxy server) and choosing 'Specify proxy address' it still doesn't work. However if I specify an alternate Squid HTTP proxy, both fb2k versions work. However that's not desirable for a few reasons (including Squid proxy sort of breaking playback when ICY dynamic track titles are enabled).

Is there a debug mode I can enable in fb2k to log its network internals while it sets up proxy connections? I've got a wireshark from my machine and can send privately, don't wish to share publicly as it obviously has details of our corporate network.
Don't forget International Talk Like A Pirate Day! September the 19th!

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #3
I guess you may not be using a proxy, I am. Sorry, forgot to mention this small but important detail!

Perhaps Apache webproxy refuses to accept "1.x" as a valid header? Not sure, would be slightly unreasonable if so. I can't see anything else obviously wrong but I can't see exactly how fb2k v1.4.2 is trying to handshake the connection as I don't control our corporate proxies.
I doubt you're going to find the issue without being able to look at the server logs. Something in the server configuration is probably rejecting your connection and debugging on foobar's end probably won't help you. It very well could be something as stupid as rejecting the "1.x" as a valid header or could be something completely unrelated. Firewall even. Going to be difficult to narrow it down without the server log.

However if I specify an alternate Squid HTTP proxy, both fb2k versions work. However that's not desirable for a few reasons (including Squid proxy sort of breaking playback when ICY dynamic track titles are enabled).
I don't seem to have this problem using a squid proxy when dynamic track titles are enabled. Does that happen regularly on all streams with dynamic metadata? Is it after a specific amount of time that this happens? Is it a specific stream codec? Could it be something in the squid config causing the problem? If you have access to squid's logs, do they tell you anything? Have you tried running a clean portable install to see if a component could somehow be causing the breaking in playback?

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #4
That would be indicative of the HTTP proxy eating up the "icy-metaint" header coming back from the stream server.

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #5
I guess you may not be using a proxy, I am. Sorry, forgot to mention this small but important detail!

Perhaps Apache webproxy refuses to accept "1.x" as a valid header? Not sure, would be slightly unreasonable if so. I can't see anything else obviously wrong but I can't see exactly how fb2k v1.4.2 is trying to handshake the connection as I don't control our corporate proxies.
I doubt you're going to find the issue without being able to look at the server logs. Something in the server configuration is probably rejecting your connection and debugging on foobar's end probably won't help you. It very well could be something as stupid as rejecting the "1.x" as a valid header or could be something completely unrelated. Firewall even. Going to be difficult to narrow it down without the server log.

Very true. I'll see if I can speak to the people who look after our proxies and see if it's a quirk of that particular proxy's configuration. I'll update when I know more.

Is there a reason FB2K 1.4 no longer reports its version number, using 1.x instead? As someone who also operates an Icecast server, I find it useful to get listener stats. I know user-agents can be arbitrary but 1.x seems a strange thing to send :)

However if I specify an alternate Squid HTTP proxy, both fb2k versions work. However that's not desirable for a few reasons (including Squid proxy sort of breaking playback when ICY dynamic track titles are enabled).

I don't seem to have this problem using a squid proxy when dynamic track titles are enabled. Does that happen regularly on all streams with dynamic metadata? Is it after a specific amount of time that this happens? Is it a specific stream codec? Could it be something in the squid config causing the problem? If you have access to squid's logs, do they tell you anything? Have you tried running a clean portable install to see if a component could somehow be causing the breaking in playback?

Yep, any Shoutcast (eg. Bassdrive, but anything) which streams MP3. Vorbis and OggFLAC streams don't have this issue, it's just Shoutcast/MP3. It's always happened to me - minute 'dips' in the audio, glitches, like the proxy's dropping then immediately reopening the connection mid-stream. Happens in sync with any metadata change. Just accepted it as a strange behaviour of our corporate proxies.

Tested the same on installs of 1.3 and older, portable 1.3.2 and portable 1.4.

First read about it on the wiki, now I just accept I have to disable dynamic metadata to get gap-free listening.

It's a shame there's no way to enable automated enable/disable of dynamic metadata based on proxy used :)
Don't forget International Talk Like A Pirate Day! September the 19th!

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #6
Re user agent - noted, we'll go back to serving actual version numbers if it makes some strangely configured proxies happy.

Re shoutcast metadata vs proxy, I'm adding a switch to disable it for proxies. Another solution would be to force the proxy to be accessed via HTTP CONNECT not GET - which is already done if connecting to HTTPS servers, just not plain HTTP. I will add a switch for that as well.
Microsoft Windows: We can't script here, this is bat country.

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #7
Re user agent - noted, we'll go back to serving actual version numbers if it makes some strangely configured proxies happy.

Re shoutcast metadata vs proxy, I'm adding a switch to disable it for proxies. Another solution would be to force the proxy to be accessed via HTTP CONNECT not GET - which is already done if connecting to HTTPS servers, just not plain HTTP. I will add a switch for that as well.

Ah, super! I've enquired with our network administrators and I'll let you know if it is the version number which was causing the issue with the Apache proxy.

One quirk of our company's setup is that our Squid proxy only listens on :80, even for TLS connections. It happily transports CONNECT sessions over :80 but we do not have an HTTPS proxy for TLS on :443.

It would be very useful if you could add some feature for fb2k to attempt a CONNECT via the proxy, even if it's not explicitly declared as HTTPS.
Don't forget International Talk Like A Pirate Day! September the 19th!

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #8
Spoke to one of our netadmins. He pointed out that the new version is also failing to supply a 'Host' header in the request:

Code: [Select]
	< Host: bbcmedia.ic.llnwd.net

< User-Agent: foobar2000/1.3.20
> User-Agent: foobar2000/1.x

< HTTP/1.1 200 OK
> HTTP/1.1 400 Bad Request

Apparently host header fields are mandatory for HTTP/1.1 requests per RFC. (TIL...)

He manually tested, adding a host header, and it returned an OK response instead of the 400.
Don't forget International Talk Like A Pirate Day! September the 19th!

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #9
Interesting, thanks for the info. Host header with proxy will be added in 1.4.3 final.
In meanwhile, 1.4.3 beta 2 has an option to force HTTP CONNECT for all proxy traffic, encrypted or not (without it only encrypted connections use CONNECT).
Microsoft Windows: We can't script here, this is bat country.

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #10
Beta 3 includes the host fix.
Microsoft Windows: We can't script here, this is bat country.

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #11
Beta 3 includes the host fix.

Apache connect now works! Trying with Beta 4.

I tried forcing a CONNECT through the Apache webproxy to see what it would do - unsurprisingly, didn't get far (far-end service is HTTP, not HTTPS). However I noticed the Host header field may be being incorrectly set, From a Wireshark session:

Code: [Select]
CONNECT bbcmedia.ic.llnwd.net:80 HTTP/1.1
Host: proxyaddress
AIUI the Host should normally be the requested far-end resource (e.g., "Host: bbcmedia.ic.llnwd.net"). I think the reason it's working now is because Apache is seeing the Host header, but it's not strictly validating it. I think it might cause issues if an HTTPS resource is requested which uses SNI to determine certificate validity...

Comparing fb2k with a few other requests from same wireshark session:

Code: [Select]
CONNECT www.ipchicken.com:443 HTTP/1.1
Host: www.ipchicken.com:443

Code: [Select]
GET http://http.00.s.sophosxl.net/V3/01/cynl.tbbtyr.pbz.m/ HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: SXL/3.1
Proxy-Connection: Keep-Alive
Host: http.00.s.sophosxl.net

Code: [Select]
CONNECT play.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:65.0) Gecko/20100101 Firefox/65.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: play.google.com:443

Thanks for your hard work so far, and for implementing a fix and a new feature so quickly! Very impressive once again :)

The force HTTP CONNECT option I will try out with some HTTPS resources and report back.
Don't forget International Talk Like A Pirate Day! September the 19th!

 

Re: fb2k 1.4.2 cannot play stream with a session variable in the URL, 1.3.2 works OK

Reply #12
Thanks for the details.
Another day, another beta, HOST handling changed again in beta 5.

As for CONNECT-
foobar2000 1.4.x only allows CONNECT with HTTPS resources regardless of this option, otherwise the proxy decrypts all your traffic defeating the whole point of HTTPS. This is why proxy handling was rewritten in 1.4, past versions did not support CONNECT.
The new option only makes fb2k attempt to use CONNECT with plain HTTP resources as well.
Microsoft Windows: We can't script here, this is bat country.