4 ms·
I believe it was added as the `itms-services://?` URL format is non-standard and broke the existing logic in `urllib.parse`: https://github.com/python/cpython/p
by 7A2A-4AC 2y ago
I believe it was added as the `itms-services://?` URL format is non-standard and broke the existing logic in `urllib.parse`: https://github.com/python/cpython/pull/104312 https://github.com/python/cpython/pull/104312
- dwaite 2y agoMy understanding per RFC 3986 is this is a valid URL. The authority consists of a host with a blank name and blank path (path-abempty). The issue is a lot of libraries do not make a distinction between a field explicitly being declared blank and being left undeclared (e.g. nil vs ""). Looks like rather than change python's URL library to recognize this distinction, they created an exception list that just hard-codes output behavior. One can make a case that client software should be robust enough to handle both forms of URL (e.g. itms-service URLs are likely just URI, but the original developers thought all URI should have two forward slashes in them). I can say specifically for "scheme://" calls that such robustness on the recipient side is very rare, because if they understood URI well enough to be robust then they wouldn't have had two extra slashes that they will never use.
- lilyball 2y agoA comment on the issue linked from the PR references https://url.spec.whatwg.org/#url-serializing https://url.spec.whatwg.org/#url-serializing as a rationale for why itms-services would normally not have the "//" and therefore needs the exception. However that standard says non-null, not non-empty¹, so it sounds like python's URL library is actually just wrong here in that it's treating an empty host the same as null. ¹Also I checked, that standard does actually define an empty host (https://url.spec.whatwg.org/#empty-host https://url.spec.whatwg.org/#empty-host) as a distinct concept from a null host.