Re: [url] Andrzej's notes

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2022-08-24 08:03:56

śr., 24 sie 2022 o 01:37 Vinnie Falco via Boost <boost_at_[hidden]>
napisał(a):

> On Tue, Aug 23, 2022 at 4:23 PM Gavin Lambert via Boost
> <boost_at_[hidden]> wrote:
> > >      url_base& url_base::set_port( string_view ); // throws
> > >      result<void> url_base::try_set_port( string_view ); // returns
> result
> > >
> > Why is it a string at all?  Shouldn't it be exclusively a uint16_t?
>
> Its a good question. Every member function in the reference has a BNF
> section which shows the grammar, and a Specification section which
> provides a link to the relevant specifications document (RFC3986 in
> this case):
>
> <
> https://master.url.cpp.al/url/ref/boost__urls__url_base/set_port/overload2.html
> >
>
> The RFC says:
>
>     port          = *DIGIT
>
> That means that "80", "443", and "8080" are examples of valid ports.
> "65535" is a valid port. But so is "4294967295" or even
> "999999999999999999". In fact "0" is a valid port, as well as "00" or
> any number of leading zeroes, followed by any number of digits
> (including no digits). And the empty string "" is a valid port.
> Boost.URL recognizes the distinction between having a port which is
> the empty string, and not having a port at all, by providing the
> function remove_port() and the function has_port(). Calling
> set_port("") is semantically different from calling remove_port(), and
> results in a different URL. This is per the RFC grammar:
>
>     authority   = [ userinfo "@" ] host [ ":" port ]
>
>
> Because this library is capable of representing ALL URLs, it is
> necessary for the interface to allow the caller to interact with the
> port as a string which is valid according to the grammar.

Is this the only reason? I would think that the primary reason is
performance: usually you obtain a URL as a string, so the port-string is
just sitting there. Then you may want to set it in another URL, so it will
be a string again.

But of
> course people need to treat it like an integer so we have overloads
> for setting the port as a sixteen bit unsigned number, and retrieving
> the port as the same.
>
> <https://master.url.cpp.al/url/ref/boost__urls__url/port_number.html>
> <
> https://master.url.cpp.al/url/ref/boost__urls__url/set_port/overload1.html
> >
>

Oh, it wasn't clear from the docs.

So, it looks like you are saying "I know it's an integer port number, you
know it's an integer port number, but I need to keep it as string because
other schemes may use it for their own murky schemes, like:
"ak://www.boost.org" -- identifies one resource
"ak://www.boost.org:" -- identifies another resource

This convinces me even further that I might want a type like http_url with
a tighter invariant:
1. The port is an optional int
2. The query part doesn't have duplicate keys.

Regards,
&rzej;