Re: [cpp-netlib-devel] URI status

[Jeroen H. <vex...@gm...>]

On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <vex...@gm...> wrote:
>> On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris
>> <mik...@gm...> wrote:
>>>
>>> So how do you build the correct type of URI from a given string?
>>>
>>> http::uri = "http://www.boost.org"; // should be valid, has URI parts
>>> smtp::uri = "http://www.boost.org"; // should be invalid, has different parts
>>>
>>
>> The current generic URI parser will parse the string into the
>> following structure:
>> struct uri_parts {
>>    optional<string_type> scheme;
>>    optional<string_type> user_info
>>    optional<string_type> host
>>    optional<uint16_t> port
>>    string_type path
>>    optional<string_type> query;
>>    optional<string_type> fragment;
>> }
>>
>> Note the path here may be defined as empty (thus "") by the RFC, but
>> that's different from being omitted.
>>
>> The first thing to notice is, that even scheme is optional. This way
>> we can support relative URI's like "../a/b?foo=bar", and can later
>> support resolving an absolute and relative URI. Secondly it might make
>> sense to parse user_info into a separate user and password, but this
>> is not specified by the RFC.
>>
>
> Personally I don't see why we're going to even support relative URI's
> especially since we want to make request generation simple with the
> interface.
>
> Unless you're also going to implement a URI builder interface where
> you can generate "correct" URI's programmatically with C++, I don't
> see whether supporting relative URI's is going to be a "plus". I may
> not be seeing the utility of that especially for a client library.
>
>> Then in uri::http you can simply check whether the URI scheme exists,
>> and is "http" or "https", and check that a host exists (the generic
>> parser already guarantees that if it exists it isn't empty), marking
>> the URI invalid if these checks fail.
>>
>
> Because currently the HTTP URI parses the string at construction time
> (and URI's are immutable anyway), validity checks are as simple as
> returning a boolean. So parse once, validity and data are available
> right away once the object is constructed.

This is indeed very nice, and should be kept this way, in what I'm
proposing -with the exception of relative URI's, see below- will be
kept that way, mere the place where most of the parsing is done will
change.

> In what you're proposing, how do you know if it's a valid URI if it's
> relative (if you're going to support it) and that it's also using the
> correct scheme (if it's omitted)?
>
>> For the uri::smtp (the format is
>> smtp://[username@]host[:port][?options]) you simply check if the
>> scheme is "smtp", check that a host exists (and maybe that fragment
>> does not) and the path is empty, again marking the URI invalid if
>> those demands aren't met.
>>
>
> If you are going to allow relative URI's, will that be valid for SMTP
> too? What would be the host?
>

You're right, adding relative URI support will increase the complexity
of the library more than I initially thought. I'm going to leave it
out, at least for now. Implementing it later shouldn't be a problem if
for any reason we choose to do so.

>>>
>>> No! Just rebase your current fork, and continue working on that. No
>>> need for a new fork!
>>>
>>
>> Ok.
>>
>
> Thanks, looking forward to progress in this front. ;)
>
> --
> Dean Michael Berris
> cplusplus-soup.com | twitter.com/deanberris
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>

Thank you for your thoughts, you might just have prevented me from
overcomplicating things :)

Jeroen