Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-06-07 14:57:56


On Tue, Jun 7, 2022 at 7:41 AM Julien Blanc via Boost
<boost_at_[hidden]> wrote:
> 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_authority.html>

Thanks


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk