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 should actually happen here is one of two things:
1. The result is a simple concatenation: "mailto:[email protected]";.
2. An exception is raised indicating that urljoin cannot determine how to
handle merging base and url.
The above could happen in cases where either scheme is None for both base and
url or the scheme to be used is any of urllib.parse.non_hierarchical.
> A more awkward question is if this behaviour of my patch is reasonable:
>
>>>> urljoin('mailto:person-foo/[email protected]', 'bar.com')
> 'mailto:person-foo/bar.com'
A couple thoughts on this: If urllib.parse.non_hierarchical is used to
determine merge vs. simple concat (or exception), this specific case won't be
an issue. Also, according to 6068, "mailto:person-foo/[email protected]' is
invalid (the "/" should be percent-encoded), but I don't think it should be the
job of urljoin to understand the URI structures of each protocol, outside of
logically join base and url.
> 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, so that urljoin() works for arbitrary schemes except for ones like
> “mailto:” that are in the hard-coded list.
This list may already be present in urllib.parse.non_hierarchical. I also think
it's worthwhile to do some further research against
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml to ensure the
list is up to date.
If this path is chosen, I would suggest getting sign off from a couple core
devs prior to investing time in this as all changes discussed so far are
backwards incompatible.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue18828>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
