Potential Incorrect Acceptance Handling in parseUrl() for Port Parameter

[bfelpsy]

The custom parseUrl() implementation contains a potential edge case issue regarding the parsing of ports.

Consider the following group in the regular expression that determines basic acceptance of the URL: StringUtilities.cpp#L61-L62

 // optional port
"(?::([[:digit:]]+))?"

This expression will accept an arbitrary digit sequence with length >=1, including numbers which are larger than the uint16_t that are used for port numbers.

On a match with port number content, StringUtilities.cpp#L90-L93 will use the custom LexicalCast.h based implementation to unconditionally convert the port:

 if (!port.empty())
{
    pUrl.port = beast::lexicalCast<std::uint16_t>(port);
}

Although benign, the code appears to incorrectly accept ports that are out of range and should have been rejected as an invalid URL. Instead it handles them as port 0 by falling back to the default uint16_t value. Additionally, port 0 is also accepted when used in the URL directly.

[nbougalis]

Thank you for reporting this issue. I agree that it's a bug. The "quick" fix is to fail parsing if the port is specified and the parsed value is 0 and I think that's reasonable enough.