[MPlayer-dev-eng] Re: [PATCH] fix for issue cant play filenames with spaces

[adland]

> hmm, the thing is more complex than i first tought.

yes but it can be fixed with more effort. 

> My patch fix escaping the url, but looks like the url is escaped again  
> elsewhere before being put on the http GET command. So it's not useful  
> at all in this situation.
> 
> So we have:
>  - my patch fix escaping of already escaped url for protocols that  
> don't change the url anymore (ex. realrtsp)
>  - url are still broken for http, because they get escaped again while  
> doing http protocol.
> 
> How do other protocols behave (mms and such)?

I have to check on this for specific examples
but believe they are not escaped as this was an issue
for some streams. (reason patch for escaping url was added)

> 
> So i think we have two solution:
> 1. unescape urls before escaping them everywhere in the code (better  
> doing it in url_escape_string)
  
this is probably critical (must be done) as escaping a url alreday escaped
causes issues and we cant be sure the url input is not previously escaped.

unsure if it should be in url_escape string function.

Just note; according to the rfc (spec) unescaping the same string twice
 also is a possible problem.

I posted a new url unescape function as a few issues were in the current
implementation.

some questions:
1. is there any way a URL is opened not from within libmpdemux/open.c
open_stream function? 
I will check on this.

2. could we add a status flag to the url structure to keep track of encoded 
status (to help prevent accidental double encoding/decoding)

check/set status in url_escape and url_unescape functions?
url input/creation -> status unknown
we unescape url -> status unescaped
we escape url before sending request to server - > status escaped

if we attempt either function again and it has been done once before
 we print out an error and return doing nothing.

if we try to send a request and status is not escaped we print an error.

errors would possibly indicate issues in code which needed fixed.

> 2. modify url_escape_string to avoid escaping of escape sequences, like  
> adland did.
> 

This is probably not a good change as Bertrand said.
but it could be a last resort if a previously escaped string makes it into the
url_escape function somehow.
I would not rescape escaped chars but print an error here as well to indicate
 something needs fixed.

please comment.
 
> The other fixes are not so important,  
> the diff. I'll apply them whet the main problem is fixed.

Okay