[issue1698] urlparse and usernames containing @

Senthil added the comment: The patch against the trunk could also have been applied to 2.5. There is NO change in the trunk and 2.4-maint patch. Thanks, Senthil __ Tracker <[EMAIL PROTECTED]> __ _

[issue1698] urlparse and usernames containing @

Senthil added the comment: Thank you, Yes having it in the 2.5.2 would be a good idea. The bug report is also on 2.5 only. I have attached the patch for the release25-maint branch. Thanks, Senthil Added file: http://bugs.python.org/file9102/issue6898-r25-maint.patch ___

[issue1698] urlparse and usernames containing @

Guido van Rossum added the comment: Committed revision 59726. This is in the trunk (2.6). Do you need this backported to 2.5.2 as well? -- keywords: +patch status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1698] urlparse and usernames containing @

Senthil added the comment: Hi Guido, I have added the unit tests, tested it on my system and created a new patch combining the previous one against the trunk. You can verify and check in this. Thank you, Senthil Added file: http://bugs.python.org/file9054/issue1698-withtests.patch ___

[issue1698] urlparse and usernames containing @

Guido van Rossum added the comment: Could you please add a unit test for this? Then I can check it in. I'm thinking this could safely be fixed in 2.5.2. -- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted __ Tracker <[EMAIL PROTECTED]

[issue1698] urlparse and usernames containing @

Senthil added the comment: > > Olivier Croquette added the comment: > > And about the decoding, sorry, it's clear from your snippets that > urlparse doesn't do it: > >>> print q.username > user%40xyz > > Maybe it should do it, I am not sure. What do you think? It would save > work for the modu

[issue1698] urlparse and usernames containing @

Senthil added the comment: > Olivier Croquette added the comment: > > > The problem right now is that urlparse parses silently an URL which is > not compliant, but does the wrong thing with it (since usernames can > contain @, and hostname can not, it's a more logical thing to parse from > the

[issue1698] urlparse and usernames containing @

Olivier Croquette added the comment: And about the decoding, sorry, it's clear from your snippets that urlparse doesn't do it: >>> print q.username user%40xyz Maybe it should do it, I am not sure. What do you think? It would save work for the module user. __ Trac

[issue1698] urlparse and usernames containing @

Olivier Croquette added the comment: See also the related bug on duplicity: http://savannah.nongnu.org/bugs/?21475 __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1698] urlparse and usernames containing @

Olivier Croquette added the comment: Hi! Thanks for the reply! The problem right now is that urlparse parses silently an URL which is not compliant, but does the wrong thing with it (since usernames can contain @, and hostname can not, it's a more logical thing to parse from the right using rsp

[issue1698] urlparse and usernames containing @

Senthil added the comment: Hi ocroquette, Even though I have seen ftp sites requesting email addresses as user names, I would rather put this issue for discussion as this not per any RFC. urlparse is based upon RFC1808 and it points to RFC1738 for the URL Syntax. RFC1738 specifically says (line

[issue1698] urlparse and usernames containing @

New submission from Olivier Croquette: Some servers allow the @ character is usernames. It gives URLs like: ftp://[EMAIL PROTECTED]@host/dir [EMAIL PROTECTED] could for example by an email address. I am not sure if this is RFC compliant. What's sure is that is makes trouble with urlparse: >>