Bugzilla – Bug 4652
Problem with pathFromFileURL and # character
Last modified: 2007-10-23 09:44:04 UTC
pathFromFileURL doesn't behave correctly when passed a URL containing the # character. I wrote a little script that sends http requests to SlimServer to play tracks. This works fine until you request a track with a # in the filename. Example: 2007-01-09 22:39:25.3843 HTTP request: from 127.0.0.1 (HTTP::Daemon::ClientConn=GLOB(0x5bb8fec)) for GET HTTP/1.1 /statu s.txt?p0=playlist&p1=play&p2=file%3A%2F%2F%2FE%3A%5CAir%5C10%2C000%20Hz%20Legend%5C03%20Radio%20%231.mp3&player=92:be:92 :55:ac:7c 2007-01-09 22:39:25.3920 HTTP parameter p0 = playlist 2007-01-09 22:39:25.3923 HTTP parameter p1 = play 2007-01-09 22:39:25.3927 HTTP parameter p2 = file:///E:\Air\10,000 Hz Legend\03 Radio #1.mp3 2007-01-09 22:39:25.3979 HTTP parameter player = 92:be:92:55:ac:7c 2007-01-09 22:39:25.4024 processURL Clients: 10.10.99.100:43339 127.0.0.1:1275 2007-01-09 22:39:25.4070 Got /E:/Air/10,000%20Hz%20Legend/03%20Radio%20 from file url file:///E:/Air/10,000 Hz Legend/03 Radio #1.mp3 2007-01-09 22:39:25.4079 extracted: E:\Air\10,000 Hz Legend\03 Radio from file:///E:/Air/10,000 Hz Legend/03 Radio #1.m p3 2007-01-09 22:39:25.4086 scanPathOrURL: Finding valid files in: E:\Air\10,000 Hz Legend\03 Radio On the 'Got' line, the path is truncated at the # character, after URI->path() function is called. I believe this is valid behaviour as the # character denotes a URI fragment, but it is not correct in this situation?
Here's the output when the same track is selected from within the web interface - note the input to the function is escaped but wasn't in previous example: 2007-01-09 22:55:06.7735 Got /E:/Air/10,000%20Hz%20Legend/03%20Radio%20%231.mp3 from file url file:///E:/Air/10,000%20Hz %20Legend/03%20Radio%20%231.mp3 2007-01-09 22:55:06.7746 extracted: E:\Air\10,000 Hz Legend\03 Radio #1.mp3 from file:///E:/Air/10,000%20Hz%20Legend/03% 20Radio%20%231.mp3
Hi James. I see what you're talking about, but I don't know if 'fixing' it might break something else. Have you had a chance to ask about it in the developer forum on our message board? Both internal and contributor developers hang out there and usually know more than I do about the ins and outs of the CLI.
I resolved this for my purposes by double-escaping the file url but I still think this is an issue...
Created attachment 1815 [details] Patch Should fix 99% of real-world occurrences.
My mistake. This is a different issue than bug 4709, for which the patch applies. I don't see any problems in normal use with files containing the # character. So this is only a problem when using status.txt, correct? I thought status.txt had been deprecated...
If there's a compelling reason to continue working on this let us know.