urllib.parse.urlsplit() in Python3.3 behaves the same way. Since urlsplit takes an optional param "allow_fragments", I don't think it should be a high priority issue.

The relevant code from Python3.3 is below, however:

    if allow_fragments and '#' in url:
        url, fragment = url.split('#', 1)
    if '?' in url:
        url, query = url.split('?', 1)

Note that passwords containing '?' would produce a similar result, which is perhaps mildly more concerning, as there is no flag to ignore the query portion of the url.

That being said, I'm against making any changes to urlsplit at this point, since that would also require modifying urlunsplit and may in fact make it much more difficult (or impossible) to rejoin a url. The strength of the very simple implementation we have currently is that it's always reversible.

anh, nice catch.

Madison, I'm not see any terrible consequences, only urlsplit is affected now:
>>> urlsplit('http://user:password@domain.com:80/path?query#fragment')
SplitResult(scheme='http', netloc='user:password@domain.com:80', path='/path', query='query', fragment='fragment')
>>> urlunsplit(_)
'http://user:password@domain.com:80/path?query#fragment'
>>> urlunsplit(('http', 'user:pass#ord@domain.com:80', '/path', 'query', 'fragment'))
'http://user:pass#ord@domain.com:80/path?query#fragment'

My apologies -- that was an oversight on my part. Now that I look at the issue again, it's plain that it most likely won't be an issue. Problems only arise when you allow '#' to occur before '?' and then treat portion of the url between the '#' and '?' as a fragment. In this scenario, when the url is rejoined, the order of the fragment and query is switched by urlunsplit().

However, since the portion of the url with a hashtag would be treated as a the netloc, this isn't any cause for concern. We only need to ensure that the order of the components is maintained.

Thanks for the heads up, Dmi.

Here's a potential patch for the issue, should we decide it's worth fixing.

All current tests pass with the update version of _splitnetloc(), and I've added a test to test_urlparse to check that urls with '#' or '?' in the password field are treated properly.

Possibly related: bpo-23328. I would have thought any special characters in the password etc field should be encoded. Where do such unencoded URLs come from?

It seems that this would change the behaviour of parsing a URL such as

http://host/path/with/unencoded/@/character

Is one of these scenarios more valid than the other?

Today I read RFC 3986, and I think the URLs in the bug reports are valid, and are already parsed correctly. The path is allowed to have a literal “at” symbol:

path-abempty = *( "/" segment )
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

The query and fragment are allowed to have “at” and question marks:

query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )

So I think this could be closed because the parsing is working correctly.

tl;dr: '#', '?' and a few other characters should be URL-encoded/%-encoded when they appear in userinfo which will already parse correctly.

---

Following up on what Martin said, RFC 3986 has the specifications for how these examples should be parsed.

userinfo = *( unreserved / pct-encoded / sub-delims / ":" )

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Notably, gen-delims are _not_ included in the allowed characters, nor are non-ASCII characters.

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

These and other characters not mentioned should be URL-encoded/%-encoded if they appear in the password.

Taking the first example:

>>> from urllib.parse import urlparse
>>> u = 'http://auser:secr%23et@192.168.0.1:8080/a/b/c.html'
>>> urlparse(u)
ParseResult(scheme='http', netloc='auser:secr%23et@192.168.0.1:8080', path='/a/b/c.html', params='', query='', fragment='')
>>> unquote(urlparse(u).password)
'secr#et'

Not a bug. The message #msg375109 explains how to quote and unquote the '#' in the password field, and demonstrates how urllib parses it correctly.

I guess, it was set to open as a mistake. Closing it again.