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]>
> 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
> > >
> > 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):
> 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.
> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk