Re: [cpp-netlib-devel] URI status

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

On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <vex...@gm...> wrote:
>> On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris
>> <mik...@gm...> wrote:
>>>
>>> Okay, I hope you realize that the URI's are not just going to be for
>>> HTTP, and that we do want support FTP, SMTP, and other protocols. I
>>> don't see how you can do this without the specific parser dispatched
>>> by tag.
>>>
>>
>> Yes, what I meant, the new generic parser will actually do this all
>> correctly, it now knows the difference between scheme://.. and
>> scheme:.. and things like that, thus the new derived objects will only
>> have to do checks like "Is the scheme actually 'http'", it won't have
>> to do any more specific parsing.
>>
>
> 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.

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.

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 don't have the specific parsing (granted that the rules are
> very different for either type of URI) I don't see how that could be
> done.
>
>>>
>>> I'd like the optional to be exposed too, that's a good idea. I've been
>>> thinking about it for a while already and I remember having that as
>>> one of the things to change.
>>>
>>> If you want to change that and the tests to reflect the new interface
>>> exposing the optional<>'s then that would be great. :)
>>>
>>
>> Great, I'll change them to reflect that.
>>
>
> Cool. :)
>
>>>> Jeroen Habraken
>>>>
>>>> [1] This is currently not committed to git yet, I have still to
>>>> properly figure out GitHub, and fork the right branch
>>>>
>>>
>>> Actually, you can continue working on your fork and just ask me to
>>> pull when you feel like it's all fine. The fork is basically your
>>> branch from master that you maintain.
>>>
>>> I for one will keep continuing to work with 0.5-devel to implement the
>>> other tags and other client types in time for release by the end of
>>> the month. If you look at the latest (which you should rebase to) in
>>> master, it would show that I've merged the HTTP Server and HTTP 1.1
>>> Client with chunked encoding support (as well as HTTPS).
>>>
>>> If you're familiar with Git already, then think of your fork as just
>>> another repository. Nothing special, you can do whatever you want with
>>> your repository. Once you're done making changes in your repository
>>> and want to have me integrate your changes to be the "official"
>>> release, then you send me a pull request from your master branch --
>>> I'll take care of the merging to cpp-netlib.
>>>
>>> HTH
>>>
>>> --
>>> Dean Michael Berris
>>> cplusplus-soup.com | twitter.com/deanberris
>>> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>>>
>>
>> Great, I think I'll make a new fork, specifically off the 0.5-devel
>> branch so things won't have to be merged with the master until
>> necessary.
>>
>
> No! Just rebase your current fork, and continue working on that. No
> need for a new fork!
>

Ok.

> --
> Dean Michael Berris
> cplusplus-soup.com | twitter.com/deanberris
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>

Jeroen