[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: Recording bugs reports for specific schemes as dependencies of this: Issue 25895: ws(s) Issue 16134: rtmp(e/s/t) Issue 23759: coap(s) -- dependencies: +Add support for RTMP schemes to urlparse, urllib.parse.urljoin does not handle WebSocket URLs, urllib

[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: If necessary, we can add a new non_relative list, rather than changing non_hierarchical. The repository history shows that “non_hierarchical” was updated with new schemes once or twice, but has never been used since it was added to Python as “urlparse.py”. IMA

[issue18828] urljoin behaves differently with custom and standard schemas

Demian Brecht added the comment: > The current behaviour when no scheme is present is fairly sensible to me and > should not be changed to do string concatenation nor raise an exception Agreed. Defaulting to relative behaviour makes sense as I imagine that'll be the general use case. > I remo

[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: The current behaviour when no scheme is present is fairly sensible to me and should not be changed to do string concatenation nor raise an exception: >>> urljoin("//netloc/old/path", "new/path") '//netloc/old/new/path' I am posting urljoin-non-hier.patch as an

[issue18828] urljoin behaves differently with custom and standard schemas

Berker Peksag added the comment: > Yet another option, similar to my “any_scheme=True” flag, might be to change > from the “uses_relative” white-list to a “not_relative” black-list of URL > schemes, [...] I think this looks like a good solution. -- versions: -Python 3.3

[issue18828] urljoin behaves differently with custom and standard schemas

Demian Brecht added the comment: Also, I would suggest still including the doc changes proposed by Madison in all versions prior to 3.5. -- ___ Python tracker ___ __

[issue18828] urljoin behaves differently with custom and standard schemas

Demian Brecht added the comment: urljoin('mailto:foo@', 'bar.com') > 'mailto:bar.com' > > which seems fairly sensible to me. This is where joining arbitrary protocols gets tricky. Does it make sense to merge non-hierarchical protocols such as mailto? My initial reaction is "no" and what

[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: I opened Issue 23703 about the funny doubled bar.com result. After backing out revision 901e4e52b20a, but with my patch here applied: >>> urljoin('mailto:foo@', 'bar.com') 'mailto:bar.com' which seems fairly sensible to me. A more awkward question is if this be

[issue18828] urljoin behaves differently with custom and standard schemas

Changes by Demian Brecht : -- stage: -> patch review versions: +Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue18828] urljoin behaves differently with custom and standard schemas

Demian Brecht added the comment: > I haven’t heard any arguments against this option yet, and it didn’t break > any tests. Pre patch: >>> urljoin('mailto:foo@', 'bar.com') 'bar.com' Post patch: >>> urljoin('mailto:foo@', 'bar.com') 'mailto:bar.com/bar.com' I'm taking an educated guess here

[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: I think a global registry seems like overkill. Here is a patch to make urljoin() treat schemes more equally and work with arbitrary schemes automatically. I haven’t heard any arguments against this option yet, and it didn’t break any tests. Another option, sti

[issue18828] urljoin behaves differently with custom and standard schemas

Madison May added the comment: >How about adding a codecs.register like public API for 3.4+? A codecs style register function seems like an excellent solution to me. -- ___ Python tracker _

[issue18828] urljoin behaves differently with custom and standard schemas

Madison May added the comment: If nothing else, we should document the work around for this issue. >>> import urllib.parse >>> urllib.parse.uses_relative.append('redis') >>> urllib.parse.uses_netloc.append('redis') >>> urllib.parse.urljoin('redis://localhost:6379/0', '/1') 'redis://localhost:637

[issue18828] urljoin behaves differently with custom and standard schemas

Berker Peksag added the comment: How about adding a codecs.register like public API for 3.4+? import urllib.parse urllib.parse.schemes.register('redis', 'rtmp') or: urllib.parse.urljoin('redis://localhost:6379/0', '/1', scheme='redis') or just: urllib.parse.schemes.extend(['

[issue18828] urljoin behaves differently with custom and standard schemas

Martin Panter added the comment: Similarly, I expected this to return "rtmp://host/app?auth=token": urljoin("rtmp://host/app", "?auth=token") I'm not sure adding everybody's custom scheme to a hard-coded whitelist is the best way to do solve this. Below I have identified some other schemes no

[issue18828] urljoin behaves differently with custom and standard schemas

Changes by Madison May : -- components: +Library (Lib) ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue18828] urljoin behaves differently with custom and standard schemas

Changes by Ned Deily : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue18828] urljoin behaves differently with custom and standard schemas

Madison May added the comment: >From urllib.parse: uses_relative = ['ftp', 'http', 'gopher', 'nntp', 'imap', 'wais', 'file', 'https', 'shttp', 'mms', 'prospero', 'rtsp', 'rtspu', '', 'sftp', 'svn', 'svn+ssh'] >From urllib.parse.

[issue18828] urljoin behaves differently with custom and standard schemas

New submission from Mher Movsisyan: >>> urljoin('redis://localhost:6379/0', '/1') '/1' >>> urljoin('http://localhost:6379/0', '/1') 'http://localhost:6379/1' -- messages: 196125 nosy: mher.movsisyan priority: normal severity: normal status: open title: urljoin behaves differently with cu