On Fri, 2004-02-13 at 14:39, Troy Johnson wrote: > > > Can the password be url encoded (use %40 for the @ symbol)? May > > be worth a shot. That should absolutely work. If not, I think it can be considered a bug. If it ends up being a urllib2 bug, we may be SOL. To be clear, that is the correct and standard [1] method of encaping characters that are non-printable non-7bit-ascii or reserved URL characters [;/?:@&=+$,]. Seth wrote: > > good call! > > if someone can try that and let us know? That'd be cool. > > -sv > > I will take a peek at the urllib2 level and see what I can find out. On Fri, 2004-02-13 at 18:34, Peter M. Abraham responded: > no luck so far... but it could be Progeny... or me for the matter. To be sure, the URL should look like this: http://user:p%40ssword@host/path Also, try hitting the same (escaped) URL you put in yum.conf using a browser. If it works in the browser but not in yum, that's bad; it's a yum/urllib2 issue. On Fri, 2004-02-13 at 19:57, Javier Perez wrote: > I thought this encoding style had been eliminated in Internet Explorer > with the latest patch. > How soon until it is abolished Internet-wide... no. This is the standard/only way of escaping reserved characters in URLs. If it were to be removed/unsupported, something like 60% of the URLs out there (and hence 60% of web) would become invalid and stop working. IE's problems here are actually really interesting and show how horrible portions of the design are. I can speak on this at length if anyone is really interested but I can assure you that standard URI escaping is not going anywhere. They may do something like disallow certain "malicious" characters or character sequences from being escaped (for instance ".." can be a dangerous sequence). On this same topic, didn't MS just send something out telling everyone not to click links but to type them in manually instead as a security measure? If this kind of stuff sets precedent, we might as well go back to pen, paper, and phone and forget about this whole Internet thing. :) - Ryan [1] http://www.w3.org/Addressing/rfc1738.txt
