On Tue, Jun 7, 2022 at 7:41 AM Julien Blanc via Boost
To get back to the topic, i find boost.url choice regarding url/uri to be a very reasonable one.
Thank you. To throw some virtual chum into the mailing list waters, I would point out that the key innovations and design choices of this library are: 1. Constructed url and url_view objects are always in encoded form 2. Constructed url and url_view objects are always syntactically valid 3. Mutations on a url object always leave it in a syntactically valid state 4. Modification of a url and removal of url-encoding can be performed without allocating memory And it is also worth mentioning that the request-target in the HTTP request-line request-line = method SP request-target SP HTTP-version CRLF is not actually a URL, but this production: request-target = origin-form / absolute-form / authority-form / asterisk-form asterisk-form is just "*" so users can just use op== to detect that. origin-form and absolute-form are relative-ref and absolute-URI respectively, and may be parsed using the functions boost::urls::parse_relative_ref and boost::urls::parse_absolute_uri. authority-form however, is special, because the syntax is not valid for what the url_view and url containers allow. The authority-form is the authority part of a valid URL, which is not a valid URL when it appears by itself: authority = [ userinfo "@" ] host [ ":" port ] Therefore, to facilitate the parsing of request-target in HTTP messages, the type authority_view is provided: https://master.url.cpp.al/url/ref/boost__urls__authority_view.html And a corresponding parsing function: https://master.url.cpp.al/url/ref/boost__urls__authority_view/parse_authorit... Thanks