[MPlayer-users] Playing an URL with special characters, charset problem

[Reimar Döffinger]

On Tue, Jan 11, 2011 at 01:49:39AM +0100, Raimund Steger wrote:
> upon trying to reproduce this out of interest I notice that mplayer
> *does* seem to urldecode the requestUri before writing it to the
> HTTP request. I can confirm this with tcpdump as well as by checking
> Apache's access.log of the machine I run it against.
> 
> E. g. when testing it like so:
> 
> mplayer 'http://steg0.eu/testing/x%E4/pie.mp4'
> 
> access.log reads:
> 
> 
> 87.184.161.204 - - [11/Jan/2011:00:03:52 +0000] "GET
> /testing/x\xe4/pie.mp4 HTTP/1.0" 200 44841240 "-" "MPlayer
> SVN-r32760-4.5.2"
> 
> 
> While this might not be a great problem with current Web servers,
> AFAIK requestUris should be 7-bit, hence urlencoding. (RFC3986:
> "Once produced, a URI is always in its percent-encoded form.")
> This is how Firefox issues the request:
> 
> 
> 2a01:170:1046:0:221:28ff:fe14:b097 - - [10/Jan/2011:23:59:37 +0000]
> "GET /testing/x%E4/pie.mp4 HTTP/1.1" 404 319 "-" "Mozilla/5.0 (X11;
> U; SunOS i86pc; en-US; rv:1.9.2.6) Gecko/20100627 Firefox/3.6.6"
> 
> 
> (Firefox connects through IPv6 while mplayer falls back to IPv4,
> this is unrelated.)
> 
> I understand that things like extracting passwords out of URIs
> require parts to be decoded, but the current implementation seems to
> go a little overboard...

First, unescaping is done first so that URLs written in both escaped
and unescaped form are handled the same. Other programs do that as well.
The real issue is that there's a special check in the URL escaping
code that skips escaping of values >= 127. Probably based on some
misunderstanding of the RFC, it is there since the very first implementation
(actually it is also possible that some of the web servers used early on
in Asia actually didn't handle escaping correctly...).