Bugzilla – Bug 1789
restriction in Slim::Utils::Misc::crackURL
Last modified: 2009-09-08 09:30:16 UTC
The current regex in crackURL only allows http $string =~ m|http://(?:([^\@:]+):?([^\@]*)\@)?([^:/]+):*(\d*)(\S*)|i; changing it to: $string =~ m|\S{1,5}://(?:([^\@:]+):?([^\@]*)\@)?([^:/]+):*(\d*)(\S*)|i; allows other types of URLs. For streaming XM Radio online to slimp3, crackURL for mms:// is needed.
Crack URL should be more generic, but I'm not sure about that specific regex. Refer to rfc1738... I suggest that we create a list of supported scheme prefixes that are relevant: http:// mms:// we have some built-in URL schemes that also should be supported for itunes, etc... Vid, what do you think?
I suggested that particular regex \S{1,5} because it does work for the mms:// stream.
vid, what do you think about the mms issue?
Where is crackURL used for a non-HTTP stream? If we want to make it generic, IMO we should use the URI package to parse out the components.
Created attachment 626 [details] match against registered protocolHandlers Does something like this work for this? It should take all the active registered protocols and allow any of them to match for the crackURL. seems to work on startup, cracking all the http urls that are in the server. Testing of others will have to come from the one who needs it :)
Using crackURL on mms is needed for streaming XM Radio Online. You get the asx playlist file from that mms stream. I'll test the suggestion and post results.
That patch will work for mms.
cool. just waiting on approval from Dean or Vidur that this is acceptable for existing cases as well as the need for supported urls.
looks reasonable to me by itself. the larger problem is why non http urls are getting to crackurl.
Looks like Bill is working on an XM Radio plugin. I dont think any other urls are ever getting to crackURL.
It occurs to me that using the URI package might actually not do the cracking that Bill might need. For protocol schemes that the package is not aware of, it doesn't implement a host() method (and possibly others). I OK with kdf's change going in.
There is a MMS class in the CPAN URI package. If you are calling this from your own code, I recommend trying to use the URI package.
Your comment may not be meant for me, but I'm not (knowingly) using the CPAN URI package from my code. It's a plugin based on AlienBBC, and basically uses $ua->request(GET $get_url) in getHTTPURL.
Ok, so who's calling crackURL?
Here's the backtrace: frame 0: Slim::Utils::Misc::crackURL (C:/Program Files/SlimServer/server/Slim/Player/Protocols/HTTP.pm line 61) frame 1: Slim::Player::Protocols::HTTP::open (C:/Program Files/SlimServer/server/Slim/Player/Protocols/HTTP.pm line 44) frame 2: Slim::Player::Protocols::HTTP::new (C:/Program Files/SlimServer/server/Plugins/XMRadio.pm line 284) frame 3: Plugins::XMRadio::ProtocolHandler::new (C:/Program Files/SlimServer/server/Slim/Player/Source.pm line 1864) frame 4: Slim::Player::Source::openRemoteStream (C:/Program Files/SlimServer/server/Slim/Utils/Scan.pm line 477) frame 5: Slim::Utils::Scan::readList (C:/Program Files/SlimServer/server/Slim/Utils/Scan.pm line 121) frame 6: Slim::Utils::Scan::addToList (C:/Program Files/SlimServer/server/Slim/Control/Command.pm line 958) frame 7: Slim::Control::Command::execute (C:/Program Files/SlimServer/server/Plugins/XMRadio.pm line 225) frame 8: Plugins::XMRadio::handleIndex (C:/Program Files/SlimServer/server/Slim/Web/HTTP.pm line 746) frame 9: Slim::Web::HTTP::generateHTTPResponse (C:/Program Files/SlimServer/server/Slim/Web/HTTP.pm line 667) frame 10: Slim::Web::HTTP::processURL (C:/Program Files/SlimServer/server/Slim/Web/HTTP.pm line 531) frame 11: Slim::Web::HTTP::processHTTP (C:/Program Files/SlimServer/server/Slim/Networking/Select.pm line 115) frame 12: Slim::Networking::Select::select (C:\Program Files\SlimServer\server\slimserver.pl line 619) frame 13: main::idle (C:\Program Files\SlimServer\server\slimserver.pl line 562) frame 14: main::main (C:\Program Files\SlimServer\server\slimserver.pl line 1124)
I've been working with Bill off-bug. I don't believe the change to crackURL is necessary for his work. It turns out that it did help him with an earlier version of his plugin, but purely serendipitously - passing a mms: URL to the HTTP protocol handler with the patch makes us connect to the http: version of the URL. As we've seen previously, the http: version of a mms: URL is generally a ASX v2 version of a playlist that contains the mms: URL. As a result, we eventually connect to the mms: URL. Either way, with that latest version of his plugin, he doesn't pass mms: URLs to the HTTP protocol handler.
Getting this off the 6.1 radar - we may choose to mark it INVALID.
so, did this plugin ever start working around this issue?
Looks like the issue was resolved.
Vidur sent me a code fragment that eliminated the need for me to parse the playlist myself, and so don't need to call crackURL. I'm OK to set this to WONTFIX.