From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-23 23:36:34
On Tue, Aug 23, 2022 at 4:23 PM Gavin Lambert via Boost
> > 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
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. 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk