Enumerate differences with URI & IRI in an appendix by annevk · Pull Request #923 · whatwg/url

annevk · 2026-07-01T08:37:09Z

This focuses on the differences people seem most concerned about, namely parsing and model differences.

There's also equivalence, canonicalization, reference resolution as a standalone concept, and validity. Some of that is hinted at here.

Preview | Diff

This focuses on the differences people seem most concerned about, namely parsing and model differences. There's also equivalence, canonicalization, reference resolution as a standalone concept, and validity. Some of that is hinted at here.

annevk · 2026-07-01T12:20:28Z

Can you re-arrange the list so that I18N (IRI) and Windows issues are grouped together?

martinthomson · 2026-07-02T01:07:03Z

+ <li><p>RFC 6874 IPv6 zone identifiers are not recognized.
+ <code>http://[fe80::a%25eth0]/</code> fails.


It is worth adding a note to the introduction that mentions that this also includes analysis of other RFCs, like this?

I'm also thinking that RFC 8089 might be worth a mention, given that there is special treatment. And I guess, since this is such a large component of the logic here, Section 4.2 of RFC 9110.

domenic

This would probably also benefit from some review from RFC partisans.

I suggested one paragraph about expanding the model differences, but I still feel there's more to say. But, perhaps your intent is to focus more on concrete mismatches and deemphasize that aspect.

domenic · 2026-07-02T00:44:23Z

+</ul>
+
+
+<h3 id=uri-iri-differences-model class=no-num>Different model</h3>


I would lead with this section and make it stronger / change the framing. Something like:

This standard is based around a parser and serializer, with a structured data type (the URL record) as the intermediary. RFC 3986 and RFC 3987 are based around ABNF grammars, which can be run against input strings to produce a boolean "matches / doesn't match" verdict. (In some cases, one can infer a decomposition of the input strings into substrings by looking at which sub-productions of the RFCs match which substrings of the input. But this is tricky to do consistently.)

Similarly, it may be worth mentioning how the URL Standard approaches normalization and relative URL resolution as something done during parsing, instead of having separate Reference Resolution and Normalization and Comparison steps (especially the complex multi-step comparison ladder). Although that touches on #729 and related issues.

domenic · 2026-07-02T00:49:51Z

+ By contrast, <code>file:///path</code> parses as expected (empty host, path
+ "<code>/path</code>").
+
+ <li><p>Domain hosts of special URLs go through UTS #46 ToASCII, which converts Unicode labels


This bullet is inaccurate ("Non-special hosts are preserved verbatim") and less informative than it could be. Maybe something like

Non-ASCII domain host treatment differs. Special URLs go through UTS #\46's ToASCII, which converts Unicode labels to Punycode and lowercases ASCII labels: https://☕.EXAMPLE/ → https://xn--53h.example/. Non-special URLs are percent-encoded: foo://☕.EXAMPLE/ → foo://%E2%98%95.EXAMPLE/. This contrasts with 3986, which rejects non-ASCII hosts and only optionally lowercases them, or 3987, which suggests percent-encoding as a default with an older, buggier version to ToASCII from RFC 3490 as a fallback for an undefined set of schemes.

domenic · 2026-07-02T00:55:09Z

+ than rejected, and a bare U+0025 (%) is preserved.
+ <code>https://example.org/foo bar</code> → <code>https://example.org/foo%20bar</code>;
+ <code>https://example.com/%</code> parses distinctly from <code>https://example.com/%25</code>.
+</ul>


Notable missing cases probably worth including:

Port normalization (especially default-port elision and restriction to < 2^16)

Host percent-decoding, e.g. parsing of https://exam%70le.org/ and https://exa%23mple.org/.

IPv6 normalization (similar to what is already mentioned for IPv4)

Userinfo format; in particular the URL Standard splits at first : into username and password but the RFC deprecates the username:password format

Allowing @ in userinfo and percent-encoding it (i.e. https://a@b@example.com/)

URL code points are a superset of 3987, e.g. U+FFF0 is allowed by the URL Standard

Scheme lowercasing

domenic · 2026-07-02T00:56:27Z

+
+<ul>
+ <li><p>Non-ASCII input is percent-encoded rather than rejected.
+ <code>https://example.com/café</code> → <code>https://example.com/caf%C3%A9</code>.


This is confusing/wrong as written, since 3986 rejects them but 3987 accepts them as IRIS and then tells you how to convert them to URIs.

domenic · 2026-07-02T01:07:58Z

+<p>This appendix is non-normative. It highlights how this standard differs from RFC 3986 and
+RFC 3987, and assumes familiarity with all three. [[RFC3986]] [[RFC3987]]
+
+<p>Most of these differences also produce a <a>validation error</a>, though in practice those are


"Most" might be overclaiming, e.g. points 1, 4, 12, 15 do not, plus the ones source-commented already. "Some" or "many" seems better.

domenic · 2026-07-02T01:08:23Z

+ <code>http://[v1.fe80]/</code> fails.
+
+ <li><p>RFC 6874 IPv6 zone identifiers are not recognized.
+ <code>http://[fe80::a%25eth0]/</code> fails.


3986 and 3987 also prohibit these, so this is a bit out of place.

domenic · 2026-07-02T01:09:17Z

+ <code>http://[fe80::a%25eth0]/</code> fails.
+
+ <li><p>A <code>file:</code> URL with host "<code>localhost</code>" normalizes to an empty host.
+ <code>file://localhost/</code> → <code>file:///</code>.


3986 / 3987's optional scheme normalization also does this; might be worth mentioning similar to other cases.

domenic · 2026-07-02T01:09:48Z

+ <li><p>Percent-encoded dot segments always collapse as "<code>.</code>"/"<code>..</code>".
+ <code>/a/%2E%2E/b</code> against <code>http://example.com/</code> →
+ <code>http://example.com/b</code>. RFC 3986 only reaches the same result with optional
+ percent-encoding normalization.


Suggested change

percent-encoding normalization.

percent-encoding normalization plus optional dot-segment normalization.

domenic · 2026-07-02T01:11:26Z

+
+<p>Depending on the component, a bare U+0025 (%), U+0022 ("), U+005B ([), U+005C (\), U+005D (]),
+U+005E (^), U+0060 (`), U+007B ({), U+007C (|), or U+007D (}) can survive parsing, and
+U+0023 (#) can survive inside a fragment. Any URL that carries such a code point serializes to a


This sentence sounds exhaustive but isn't, e.g. it omits <, >, ", U+0020 in opaque paths.

annevk · 2026-07-02T06:19:50Z

Thanks for all the feedback! With the model section I wanted to focus on the representation differences. E.g., that a URL can have a path that is /% which is different from /%25. That is impossible to express in a URI.

Many differences go away after parsing because < for instance is percent-encoded. So with respect to < I believe URL and URI are aligned in terms of model/representation. It can only be expressed as %3C (or lowercase).

There are indeed also other differences such as how we deal with relative URLs, normalization, and comparison, but those feel less important.

martinthomson reviewed Jul 2, 2026

View reviewed changes

domenic reviewed Jul 2, 2026

View reviewed changes

		<li><p>RFC 6874 IPv6 zone identifiers are not recognized.
		<code>http://[fe80::a%25eth0]/</code> fails.

		</ul>


		<h3 id=uri-iri-differences-model class=no-num>Different model</h3>

	percent-encoding normalization.
	percent-encoding normalization plus optional dot-segment normalization.

Uh oh!

Conversation

annevk commented Jul 1, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

annevk commented Jul 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domenic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

annevk commented Jul 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

annevk commented Jul 1, 2026 •

edited by pr-preview Bot

Loading