Repository navigation
DNS (and other naming systems) vs the host parser #397
Description
@sleevi I was curious if we could explore #159 (comment) further to make a more principled determination about #390 and similar such issues.
Firefox hit a compatibility issue with HTTPS URLs with hyphens at the beginning or end of domain labels and also previously with underscores: https://bugzilla.mozilla.org/show_bug.cgi?id=1184059. It doesn't use this validation for HTTP URLs though. This validation being:
RFC 5280 Section 4.2.1.6 says that a dNSName "MUST be in the 'preferred name syntax', as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]" except "a dNSName of ' ' MUST NOT be used." Additionally, we allow underscores for compatibility with existing practice.
What I'm interested in is learning which naming systems are still in use and what their theoretical range of values is as well as their range of values in widely adopted implementations.
Activity
sleevi commentedon Jun 8, 2018
@annevk Its perhaps the fact that our URL parsing is trying to support more than strictly the WHATWG notion of hosts, and trying to figure out when/how those are canonicalized as such. I would be surprised if @achristensen07 doesn't run into a similar issue re: NSURL.
For example, I recently was asked to look into having
GURL(our internal URL representation that serves as our parser/canonicalizer) supportsmb://URL parsing (not for the intent of web exposure), and to support the NetBIOS naming scheme. We're not keen to bifurcate URL parsing/canonicalization more than absolutely necessary (i.e. we're not keen to have entirely separate parse/canonicalization for Web vs Chrome usages of URLs). The same nominally applies to things likechrome-extensionor other UA-extended schemes.Even within the space of certificates, during certificate linting, it was highlighted that UAs' notion of IDNs and RFC 5280s notions are non-aligned - see specifically RFC 5280, Section 7.2 and note well the use of RFC 3490, the reference to which was explicitly not updated to point to RFC 5890 or RFC 5891
I think for host, treating it as opaque (but defining the character space and escaping rules) is a desirable goal, but acknowledge that holds a host of issues regarding U-Label vs A-Label and determining when IDN policies apply.
annevk commentedon Mar 27, 2020
A way out here mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1184059#c29 might be that we have a separate "DNS domain" definition which is effectively a further validation on the output of the host parser (if it is a domain) that allows
As this definition is mainly needed by various networking standards, it doesn't necessarily have to live in the URL Standard. Fetch could be a place, but perhaps filing some issues against the relevant standards that have a dependency on the "broken" concept could also result in some action.
annevk commentedon Mar 27, 2020
cc @MattMenke2