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.
Thanks