Message333755
| Author |
martin.panter |
| Recipients |
martin.panter, nsonaniya2010, orsenthil |
| Date |
2019年01月16日.10:01:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1547632897.49.0.33726596936.issue35748@roundup.psfhosted.org> |
| In-reply-to |
| Content |
FWIW I understand the backslash should be percent-encoded in URLs, otherwise the URL is not valid.
This reminds me of a few other bugs:
* Issue 30500: Made the behaviour of fragment (#. . .) versus userinfo (. . .@) consistent, e.g. in //www.google.com#@xxx.com
* Issue 18140: Also about the ambiguity of fragment (#. . .) and query (?. . .) versus userinfo (. . .@)
* Issue 23328: Precedence of path segment (/. . .) versus userinfo (. . .@); e.g. //user/name:pass/word@www.google.com
I think people some times come up with these invalid URLs because they are trying to make a URL that includes a password with unusual characters (e.g. for the "http_proxy" environment variable). So raising an exception or otherwise changing the parsing behaviour could break those cases. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2019年01月16日 10:01:39 | martin.panter | set | recipients:
+ martin.panter, orsenthil, nsonaniya2010 |
| 2019年01月16日 10:01:37 | martin.panter | set | messageid: <1547632897.49.0.33726596936.issue35748@roundup.psfhosted.org> |
| 2019年01月16日 10:01:37 | martin.panter | link | issue35748 messages |
| 2019年01月16日 10:01:37 | martin.panter | create |
|