On Jun 6, 2022, at 5:10 PM, Gavin Lambert via Boost wrote:

I don't think anyone actually types mailto: addresses into the address bar on a browser,

I just tried it (because why not) mailto:boost@mirality.co.nz * Google Chrome - launched my mail program and created a new message * Safari - asked if I wanted to let the page create an email message and (when I said “Allow”) did so. * Brave - asked if I wanted to let the page create an email message and (and when I said “Yes”) did so. — Marshall

On Mon, Jun 6, 2022 at 8:21 PM Marshall Clow wrote:

On Jun 6, 2022, at 5:10 PM, Gavin Lambert wrote:

...

I don't think anyone actually types mailto: addresses into the address bar on a browser,

I just tried it (because why not)

mailto:boost@mirality.co.nz

* Google Chrome - launched my mail program and created a new message * Safari - asked if I wanted to let the page create an email message and (when I said “Allow”) did so. * Brave - asked if I wanted to let the page create an email message and (and when I said “Yes”) did so.

Typing mailto:user@domain.com?subject=Hello in Netscape Navigator would open Eudora and save me a few key presses. Glen

вт, 7 июн. 2022 г., 03:10 Gavin Lambert via Boost :

file is also an URL protocol, although you're correct that mailto is not. I don't think anyone actually types mailto: addresses into the address bar on a browser, though (nor can I think of any other URIs that someone might manually type, except for things like about:config that are browser-specific).

There's no such thing as "URL protocol". The distinction between a URI and a URL is purely in the way its intended to be used. Every URL is a URI, because it Uniquely Identifies a thing. Some URIs are also URLs, because you can Locate things with them. Any URI scheme can be used for a URL, and I know for a fact that you can register handlers for custom URI schemes in at least Windows, Linux, and Android. And on the other hand, http scheme is usually associated with the idea of URL. But e.g. XML namespaces are identified by URIs, often those are http URIs, and there's absolutely no guarantee that the URI can be used to retrieve some document from the Internet.

Le 2022-06-07 13:29, Mateusz Loskot via Boost a écrit :

From [1] which is one of best explanation I've came across:

[1] https://danielmiessler.com/study/difference-between-uri-url/

I wouldn't pay too much attention to this article, which reflects more the author's point of view than any academical consensus, nor the intent of the people who actually wrote the RFC. And has a poor reading of the RFC wording, for example confusing “can be classified as” and “is”. For those who can read French (I apologize for the others), https://www.bortzmeyer.org/3986.html gives a nice overview, from someone who is actually involved in the IETF. To get back to the topic, i find boost.url choice regarding url/uri to be a very reasonable one. Regards, Julien

From [1] which is one of best explanation I've came across

I've been trying to synthesize an explanation to this in the documentation. One useful resource I found is: https://datatracker.ietf.org/doc/html/rfc3305#section-2.3 The confusion is everywhere.

People who are well-versed in URI matters tend to use "URL" and "URI" in ways that seem to be interchangeable.

-- Alan Freitas https://github.com/alandefreitas

On 7/06/2022 23:21, Дмитрий Архипов wrote:

There's no such thing as "URL protocol".

I was using an abbreviation. A more correct phrasing might be "an URI scheme that denotes a protocol that uses the URL format" but that's much more of a mouthful. The parsing-level distinction between the two is generically obvious and does not require recognition of the specific scheme; if the scheme colon is immediately followed by one or more slashes then it's an URL, otherwise it is not. But this is off-topic. (Well, ok, *technically* the distinction is even more vague than this, and it's possible to have an 'URL' that doesn't lead with slashes -- it just needs to semantically represent a 'location' rather than a 'name/id'. But for practical purposes the above rule suffices, especially in the context of an URI parser, since it must treat the content as opaque if it does not have leading slashes.)

And on the other hand, http scheme is usually associated with the idea of URL. But e.g. XML namespaces are identified by URIs, often those are http URIs, and there's absolutely no guarantee that the URI can be used to retrieve some document from the Internet.

They're still URLs, regardless of whether they resolve to a valid web resource or not. (They're also URIs, of course.)

On 9/06/2022 08:40, Дмитрий Архипов wrote:

...

The parsing-level distinction between the two is generically obvious and does not require recognition of the specific scheme; if the scheme colon is immediately followed by one or more slashes then it's an URL, otherwise it is not. But this is off-topic.

This is wrong, there's absolutely no syntactic distinction between URIs and URLs. The distinction is in their purpose. Consult this section:

https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3

Which I did clarify further down. I know this is the Internet, but you don't need to pick every little nit.

The two slashes mean that URI contains the authority part. One slash means it doesn't. What it means for the URI is essentially decided by the scheme or the application authors.

Containing any leading slashes means that the URI contains a path, which means that it represents a location, which automatically makes it an URL and not an URN. As I also said, while it is technically possible for a non-slash-leading URI to semantically represent a location and thus also be an URL, this is atypical and for most intents and purposes can and should be ignored as a useless distinction. Especially in the context of a generic parser.

How could they be URLs, when they aren't supposed to be used to Locate anything, and the defining characteristic of being a URL is that it describes how to get the thing?

Any URI that uses the http protocol is (by definition) an URL, because it is representing a location. It does not stop being a location just because there is no valid resource at the server claiming to be the authority for that location at any particular point in time (or if there is no such server); that just makes it an unreachable location.

On 9/06/2022 12:28, Vinnie Falco wrote:

So.. have you seen the Boost.URL Reference Card?

https://master.url.cpp.al/url/help_card.html

That's a decent reference for URL parsing (although it's then odd that the method names state "uri", which is how this discussion started), but it's non-obvious from that how it parses non-URL URIs. From the RFC, I'm assuming you put the non-scheme component into the "path", but then the only valid operations are to get and set it as a single opaque unit, and it's *also* unclear from that reference card which of the path methods will do those things without trying to interpret its contents in some way. (I assume encoded_path/set_encoded_path.) (Side note: docs missing for https://master.url.cpp.al/url/ref/boost__urls__url/set_path.html )

On 9/06/2022 14:57, Vinnie Falco wrote:

Right, if you want to treat the path (or query) as a single unit then the corresponding members of url_view and url are used (those in the aqua and lavender boxes). However if you want to deal with the path as a const or modifiable range of segments then you use the containers returned by the functions encoded_segments() or segments().

The [encoded_]segments view is *technically* illegal for non-URL URIs (or at least non-sensible), though I suppose there's no particular harm if you just don't use it (or only use it if the data format happens to coincidentally be slash-separated, assuming it won't add stray leading slashes).

Functions with the word "set" are mutating, otherwise they are not. Functions with the word "encoded" always return percent-encoded strings. This is how things are stored natively. We should add this somewhere to the docs if it is not already there/

It would be nice to explicitly call out that the "encoded" form is the original unmodified text (and not, for example, parsed and then re-encoded). I've only really skimmed the docs at this point so I certainly might have overlooked that, but what I saw seemed to imply this but didn't really state it explicitly.

The Reference Card assumes some familiarity with the library and consolidates the bulk of the APIs of the library into one page for convenience. I'm experimenting with some new documentation ideas.

There's an example of an URN being parsed to scheme and path in the RFC; it might be nice to add that (or perhaps a mailto:) to your diagram for clarity. Although perhaps also including query and fragment parts too, since those are legal parts of the grammar.

Containing any leading slashes means that the URI contains a path, which means that it represents a location, which automatically makes it an URL and not an URN. Can you direct me to an IETF or a W3C document that says that? The only official text that I know of that distinguishes URIs and URLs is the section from URI RFC (already linked in this thread several times) and it explicitly says that

В письме от четверг, 9 июня 2022 г. 02:18:07 MSK пользователь Gavin Lambert via Boost написал: the difference between a URI and a URL is not in syntax, but in intent. Furthermore, the RFC calls "path" the part between (optional) "//" authority and (optional) "?" query. It explicitly says that path is required, but it can be empty. As such me@server.tld in mailto:me@server.tld is path. Is it a URL by your definition? Conversely, the path for http://example.com is empty. Is it still a URL?

Any URI that uses the http protocol is (by definition) an URL, because it is representing a location. Again, can you direct me to a document that spells out this feature of the http scheme?