Re: [cpp-netlib-devel] URI status

[Dean M. B. <mik...@gm...>]

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.

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?

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