Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-24 14:29:16

On Wed, Aug 24, 2022 at 1:04 AM Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> This convinces me even further that I might want a type like http_url with a tighter invariant:

Uhh.. I don't know about that. The request-target in HTTP is not
exactly a URL. From rfc7230:

     request-target = origin-form
                    / absolute-form
                    / authority-form
                    / asterisk-form

origin-form is a relative-ref which has no scheme or authority.
There's no port in it.

absolute-form is the same as absolute-URI which can have an authority.

authority-form is just an authority, can have a port, and is
technically not even a URL. That's why Boost.URL provides the type
authority_view and the function parse_authority.

And asterisk-form is literally just a single asterisk character '*'
which is also not a URL. Boost.URL does not provide a type or parser
for this because, well come on man you can parse that yourself :)

So what would http_url be? It can't be all of these things.. unless
maybe you're thinking to make it a variant. I feel that the current
model of providing url_view, url, and static_url as general purpose
containers which faithfully implement rfc3986, while leaving it to the
user to build up tighter invariants or other scheme-specific
interfaces to the general container, strikes a reasonable balance.

On a side note, it is because the specifics of the grammars matter so
much for where they are used that I have been strict in the naming of
parse functions. It is essential to use the right terms or else more
confusion results. Did you know that the request-target was sometimes
not a URL, and has a grammar that is dependent on the context (e.g.
GET versus CONNECT)? I did not... Users will need to know these things
in order to produce correct programs, and Boost.URL does its part by
being precise.


Boost list run by bdawes at, gregod at, cpdaniel at, john at