From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-01-21 19:59:28
On Tue, Jan 21, 2020 at 10:41 AM Andrey Semashev via Boost
> There is a semantic difference between URI and URL - the former is an
> identifier and the latter is a locator (i.e. a path to a resource
> location). You can treat locator as an identifier but not the other way
> around. Using the term URL to refer to an URI is confusing.
Having both terms is confusing, and WhatWG got this right. The vast
majority of users just want to "parse a URL", for example one that
comes in from an HTTP request, or one that is specified on the command
line. When they go into Google, they type "URL" they don't type "URI."
Hardly anyone knows what a URI is. But even my mother who is 90 knows
what a URL is.
I want my libraries to be popular and have mass appeal, not just
satisfy a niche audience of super-experts. When I type "URI" into
Google I get:
About 287,000,000 results (0.87 seconds)
The University of Rhode Island (top result)
People Also Ask:
What is difference URL and URI?
While they are used interchangeably, there are some subtle differences...
Now if I type "URL" into Google, I get:
About 12,620,000,000 results (0.50 seconds)
en.wikipedia.org âº wiki âº URL
URL - Wikipedia (top result)
People Also Ask:
What is the URL?
What is an example of a URL address?
How do I find URL?
What is the path in the URL?
What is URL on my phone?
What does WWW stand for?
Yes, not only is "URL" 44 times more popular than "URI" in terms of
search results, but the top question about "URI" is "What is
difference URL and URI?". While for "URL" no one is asking about the
Another way to think of it, in terms of name recognition "URI" is to
.org what "URL" is to .com. People assume that a domain name is in
.com because that's the most popular TLD. That's why .com domains go
for so much more money.
It is true that URL is not an exact fit if you adhere to the technical
documentation 100%, but I think the overall benefit of just
standardizing on the name "URL" outweighs the downsides. It is easier
for users, better for Boost, and gives the library more appeal to
> The reason I'm interested particularly in URIs is because I have to deal
> with them, not so much with URLs.
This library should do everything you want with URIs since I take care
of parsing all the top-level rules. The library does not make
assumptions about the data. For example if you want to treat the path
as just one string and ignore the segments, you can do that. If you
want to ignore the distinction between username and password in the
userinfo, you can do that too. You can treat the query params as an
associative array of key/value pairs if you want, or you can ignore
that and just work with the query directly.
If you have specific use-cases feel free to open an issue or cite them
here and I will make sure they are attended to (assuming it is
P.S. "Only snobs call it a URI" :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk