Protocol handler: URL length limits for non-DNS names
lidel opened this issue · comments
(This is a low priority, purely exploratory question)
In the future, distributed protocols may move to hash functions that produce longer outputs (more than 63 or 255 characters), and need to be able to use them in "authority" part of URLs.
I was unable to find formal length limits in WHATWG URL Spec. I know that FQDN length limits exist and are respected by DNS registrars (RFC1034: 63 characters per label, 255 in total), but what are limits for native protocol handler API, which does not formally depend on DNS spec?
Namely:
- what is the length limit of "authority" (origin) part ?
- what is the length limit of string produced by
new URL(...).toString()?
Good question. We use nsIStandardURL that extends nsIURL that extends nsIURI. Last one mention refers to bunch of rfcs among them to RFC3490: Internationalizing Domain Names in Applications (IDNA) that as far as I understand suggests 255 limit (quoting inline below):
URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent, and should limit these names to no more than
255 characters in length.
How fathefully we follow that limit, that I do not know (should be easy enough to test). But I'm worried that would be a problema never the less, as OS or some other URL parsers may follow the 255limit.
Does not seems actionable