cpp-netlib-devel

[cpp-netlib-devel] New Branch on Github

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

Hi Everyone,

So recently I've finished moving the code from Subversion to Git and
also continuing development on Github. I've made a branch 0.5-devel in
the Git repository on Github and here's what I've been doing so far.

I've been making some steady progress with supporting HTTP 1.1 by
first refactoring the current client implementation. In the 0.5-devel
branch I've renamed tags::http to tags::http_8bit_tcp_resolver (which
is the default typedef for http::client). I've created another tag
'tags::http_8bit_udp_resolver' which, when used with the
http::basic_client as the tag template parameter will actually use a
UDP resolver.

There's also a new trait dispatcher to determine the resolver policy
as well as the type of the resolver to use based on the tag provided.

Next I'll be working on the connection management policy that
dispatches based on the HTTP versions and the tag parameter. The
connection management policy will look like the following:

  HTTP Version | Tag | Behavior
  HTTP 1.1 | http_default_8bit_*_resolver | All requests default to
'Connection: close", one request one connection.
  HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host,
connections are persistent and re-usable, unless server sends
'Connection: close' to a response.
  HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active
object, results are future<basic_response<Tag> >, one request one
connection.
  HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes
active object, results are future<basic_response<Tag> >, connections
are pooled 2 per host.
  HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active
object, requests will have a function object parameter which handles
streaming data, one connection per request.
  HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes
active, requests will have a function object parameter which handles
streaming data, connections are pooled 2 per host.

In the process, I will be supporting HTTPS as a protocol in the
connection objects, using dynamic polymorphism to differentiate
between the normal TCP connections and HTTPS connections.

Questions, comments, suggestions, and contributions would be very much welcome.

Thanks in advance and I hope this helps!

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

Re: [cpp-netlib-devel] New Branch on Github

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/12/14 Dean Michael Berris <mik...@gm...>

>
> Next I'll be working on the connection management policy that
> dispatches based on the HTTP versions and the tag parameter. The
> connection management policy will look like the following:
>
>  HTTP Version | Tag | Behavior
>  HTTP 1.1 | http_default_8bit_*_resolver | All requests default to
> 'Connection: close", one request one connection.
>  HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host,
> connections are persistent and re-usable, unless server sends
> 'Connection: close' to a response.
>  HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active
> object, results are future<basic_response<Tag> >, one request one
> connection.
>  HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes
> active object, results are future<basic_response<Tag> >, connections
> are pooled 2 per host.
>  HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active
> object, requests will have a function object parameter which handles
> streaming data, one connection per request.
>  HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes
> active, requests will have a function object parameter which handles
> streaming data, connections are pooled 2 per host.
>
>
This is difficult to read in my e-mail program.  In any case, I think this
belongs on the wiki.  It would be useful to provide a catalogue of all tags
on the wiki and eventually in the quickbook docs.


> Questions, comments, suggestions, and contributions would be very much
> welcome.
>
>
`hello_world.cpp` can be repeated in `examples/server/hello_world.cpp`
(where it can therefore be documented in quickbook).  I think that's a
really nice example, an HTTP server in C++ in less than 40 lines ;)  Though
the `request_header` type is either a struct or it's using a C++0x
initializer list.

G

Re: [cpp-netlib-devel] New Branch on Github

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

On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/12/14 Dean Michael Berris <mik...@gm...>
>>
>> Next I'll be working on the connection management policy that
>> dispatches based on the HTTP versions and the tag parameter. The
>> connection management policy will look like the following:
>>
>>  HTTP Version | Tag | Behavior
>>  HTTP 1.1 | http_default_8bit_*_resolver | All requests default to
>> 'Connection: close", one request one connection.
>>  HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host,
>> connections are persistent and re-usable, unless server sends
>> 'Connection: close' to a response.
>>  HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active
>> object, results are future<basic_response<Tag> >, one request one
>> connection.
>>  HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes
>> active object, results are future<basic_response<Tag> >, connections
>> are pooled 2 per host.
>>  HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active
>> object, requests will have a function object parameter which handles
>> streaming data, one connection per request.
>>  HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes
>> active, requests will have a function object parameter which handles
>> streaming data, connections are pooled 2 per host.
>>
>
> This is difficult to read in my e-mail program.  In any case, I think this
> belongs on the wiki.  It would be useful to provide a catalogue of all tags
> on the wiki and eventually in the quickbook docs.
>
>>
>> Questions, comments, suggestions, and contributions would be very much
>> welcome.
>>
>
> `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp`
> (where it can therefore be documented in quickbook).  I think that's a
> really nice example, an HTTP server in C++ in less than 40 lines ;)  Though
> the `request_header` type is either a struct or it's using a C++0x
> initializer list.
>
> G
>

Hi,

I'm currently working on URI, and the HTTP part in specific, trying to
make it more strict, RFC compliant. The query and fragments should be
working now, the path is still a bit of a pain. I'll keep you up to
date, and expect a patch sometime soon :)

Jeroen

Re: [cpp-netlib-devel] New Branch on Github

[Glyn M. <gly...@gm...>]

Hi Jeroen,

2009/12/14 Jeroen Habraken <vex...@gm...>

>
> Hi,
>
> I'm currently working on URI, and the HTTP part in specific, trying to
> make it more strict, RFC compliant. The query and fragments should be
> working now, the path is still a bit of a pain. I'll keep you up to
> date, and expect a patch sometime soon :)
>
>
Thanks for doing this and keeping us up to date.
Glyn

Re: [cpp-netlib-devel] New Branch on Github

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

Hi Jeroen,

On Mon, Dec 14, 2009 at 5:42 PM, Jeroen Habraken <vex...@gm...> wrote:
> On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote:
[snip]
>
> I'm currently working on URI, and the HTTP part in specific, trying to
> make it more strict, RFC compliant. The query and fragments should be
> working now, the path is still a bit of a pain. I'll keep you up to
> date, and expect a patch sometime soon :)
>

Cool, please either fork the library on Github or send a git patch
later on. I will be freezing the Subversion repository tomorrow.

Have a good day!

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

Re: [cpp-netlib-devel] New Branch on Github

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

On Mon, Dec 14, 2009 at 13:03, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Jeroen,
>
> On Mon, Dec 14, 2009 at 5:42 PM, Jeroen Habraken <vex...@gm...> wrote:
>> On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote:
> [snip]
>>
>> I'm currently working on URI, and the HTTP part in specific, trying to
>> make it more strict, RFC compliant. The query and fragments should be
>> working now, the path is still a bit of a pain. I'll keep you up to
>> date, and expect a patch sometime soon :)
>>
>
> Cool, please either fork the library on Github or send a git patch
> later on. I will be freezing the Subversion repository tomorrow.

I'm currently working with version 0.4 as a base, but I should indeed
switch to trunk.

>
> Have a good day!
>
> --
> Dean Michael Berris
> blog.cplusplus-soup.com | twitter.com/mikhailberis
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>

Jeroen

Re: [cpp-netlib-devel] New Branch on Github

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

Hi Glyn,

On Mon, Dec 14, 2009 at 5:20 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/12/14 Dean Michael Berris <mik...@gm...>
>>
>> Next I'll be working on the connection management policy that
>> dispatches based on the HTTP versions and the tag parameter. The
>> connection management policy will look like the following:
>>
>>  HTTP Version | Tag | Behavior
>>  HTTP 1.1 | http_default_8bit_*_resolver | All requests default to
>> 'Connection: close", one request one connection.
>>  HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host,
>> connections are persistent and re-usable, unless server sends
>> 'Connection: close' to a response.
>>  HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active
>> object, results are future<basic_response<Tag> >, one request one
>> connection.
>>  HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes
>> active object, results are future<basic_response<Tag> >, connections
>> are pooled 2 per host.
>>  HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active
>> object, requests will have a function object parameter which handles
>> streaming data, one connection per request.
>>  HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes
>> active, requests will have a function object parameter which handles
>> streaming data, connections are pooled 2 per host.
>>
>
> This is difficult to read in my e-mail program.  In any case, I think this
> belongs on the wiki.  It would be useful to provide a catalogue of all tags
> on the wiki and eventually in the quickbook docs.
>

Indeed. I should really use the Wiki more. I'll do this on the Trac
Wiki in the meantime. I was writing this half asleep and now that I
think about it I should have used an outline instead. :D

>>
>> Questions, comments, suggestions, and contributions would be very much
>> welcome.
>>
>
> `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp`
> (where it can therefore be documented in quickbook).  I think that's a
> really nice example, an HTTP server in C++ in less than 40 lines ;)  Though
> the `request_header` type is either a struct or it's using a C++0x
> initializer list.
>

Right. The request_header is definitely just a struct (or a POD). :)

I'm still thinking about moving the request/response types as nested
types to the http::basic_client<...> and http::server<...> instead of
namespace-level types, or merging them to work for both the client and
the server. At the worst case I would make different specializations
based on the tag and type-defining them as different types
server_request/server_response at the namespace level. I find it a
little ugly in the C++ world of namespaces, but if you have other
ideas about making the naming convention more consistent I'm all ears.
:D

Have a great day everyone, and Glyn please look forward to a Wiki page
on tags and descriptions soon.

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

Re: [cpp-netlib-devel] New Branch on Github

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

On Mon, Dec 14, 2009 at 13:03, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Jeroen,
>
> On Mon, Dec 14, 2009 at 5:42 PM, Jeroen Habraken <vex...@gm...> wrote:
>> On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote:
> [snip]
>>
>> I'm currently working on URI, and the HTTP part in specific, trying to
>> make it more strict, RFC compliant. The query and fragments should be
>> working now, the path is still a bit of a pain. I'll keep you up to
>> date, and expect a patch sometime soon :)
>>
>
> Cool, please either fork the library on Github or send a git patch
> later on. I will be freezing the Subversion repository tomorrow.
>
> Have a good day!
>
> --
> Dean Michael Berris
> blog.cplusplus-soup.com | twitter.com/mikhailberis
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Hi,

I've decided to roll an initial patch, please find it attached. It
fixes the following:
- stricter RFC compliant parsing of the scheme, in the generic URI
- It converts the scheme to lower case, as it states the following in
the RFC, "For resiliency, programs interpreting URI should treat upper
case letters as equivalent to lower case in scheme names"
- I've changes the parser of the port to use ushort_ and uint16_t, the
RFC specifies the port as *digit, but I think it should be limited to
the valid network ports, thus 0 <= port <= 2**16
- The query and fragment are now parsed conform to the RFC I believe,
I'd like to change this later to parse the query into a
std::list<std::pair<string_type, string_type> >

Note that the way the current parser works, it guarantees that if the
URI is valid, the URI decoding can do with a lot less checks, I don't
know whether this is a good idea though.

Jeroen

Re: [cpp-netlib-devel] New Branch on Github

[Glyn M. <gly...@gm...>]

Dean,

2009/12/14 Dean Michael Berris <mik...@gm...>

>  >
> > `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp`
> > (where it can therefore be documented in quickbook).  I think that's a
> > really nice example, an HTTP server in C++ in less than 40 lines ;)
> Though
> > the `request_header` type is either a struct or it's using a C++0x
> > initializer list.
> >
>
>
> Right. The request_header is definitely just a struct (or a POD). :)
>

I think it's not a POD because it contains members that are of type
`std::string`.


>
> I'm still thinking about moving the request/response types as nested
> types to the http::basic_client<...> and http::server<...> instead of
> namespace-level types, or merging them to work for both the client and
> the server. At the worst case I would make different specializations
> based on the tag and type-defining them as different types
> server_request/server_response at the namespace level. I find it a
> little ugly in the C++ world of namespaces, but if you have other
> ideas about making the naming convention more consistent I'm all ears.
> :D
>
>
Why have http::basic_client and not http::basic_server?

I think nested classes could be a better approach, they will use the same
tags as the server class anyway.

Have a great day everyone, and Glyn please look forward to a Wiki page
> on tags and descriptions soon.
>

Thanks,
G

Re: [cpp-netlib-devel] New Branch on Github

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

On Mon, Dec 14, 2009 at 9:16 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2009/12/14 Dean Michael Berris <mik...@gm...>
>>
>>
>> Right. The request_header is definitely just a struct (or a POD). :)
>
> I think it's not a POD because it contains members that are of type
> `std::string`.
>

Hmmm... That's odd. GCC 4.4 doesn't complain with the use case. I
think this is still valid if it's not a POD because it allows for
"static" initialization. I remember std::string can be statically
initialized (as in, during compile time) which is why this works.

>>
>> I'm still thinking about moving the request/response types as nested
>> types to the http::basic_client<...> and http::server<...> instead of
>> namespace-level types, or merging them to work for both the client and
>> the server. At the worst case I would make different specializations
>> based on the tag and type-defining them as different types
>> server_request/server_response at the namespace level. I find it a
>> little ugly in the C++ world of namespaces, but if you have other
>> ideas about making the naming convention more consistent I'm all ears.
>> :D
>>
>
> Why have http::basic_client and not http::basic_server?
>

Was still thinking about that. I think I would implement an
http::basic_server if I can do something like tag dispatching based on
features to be supported by the basic_server specialization.

> I think nested classes could be a better approach, they will use the same
> tags as the server class anyway.
>

I agree. However that would break code that's already using
http::request for the client -- unless i typedef http::request to be
by default http::basic_client<...>::request which is just ugly. That
said, I think we can still afford to break backwards compatibility
because, well, we're header only --  and breaking changes will cause
users to actively upgrade their usage. <insert evil laughter here> :D

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

Re: [cpp-netlib-devel] New Branch on Github

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

Hi Jeroen,

On Mon, Dec 14, 2009 at 9:12 PM, Jeroen Habraken <vex...@gm...> wrote:
> On Mon, Dec 14, 2009 at 13:03, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> Cool, please either fork the library on Github or send a git patch
>> later on. I will be freezing the Subversion repository tomorrow.
>>
>> Have a good day!
>>
>
> I've decided to roll an initial patch, please find it attached. It
> fixes the following:
> - stricter RFC compliant parsing of the scheme, in the generic URI
> - It converts the scheme to lower case, as it states the following in
> the RFC, "For resiliency, programs interpreting URI should treat upper
> case letters as equivalent to lower case in scheme names"
> - I've changes the parser of the port to use ushort_ and uint16_t, the
> RFC specifies the port as *digit, but I think it should be limited to
> the valid network ports, thus 0 <= port <= 2**16
> - The query and fragment are now parsed conform to the RFC I believe,

Thanks very much for this!

> I'd like to change this later to parse the query into a
> std::list<std::pair<string_type, string_type> >
>

I'd say a function that interprets the query part doesn't have to be
part of the uri interface. I'd accept a function which would parse out
the the .query() part of the uri into a
list<pair<string_type,string_type> > that looks like this:

  list<pair<string,string> > query_list_ = query_list(uri);

This should be available via ADL and only for http uri's. The
simplicity of the HttpUri concept should be preserved. Also, I'd
imagine the query_list(...) function to dispatch to a specific
implementation based on the tag associated with the uri. This is so
that we can change the result type based on the tag associated with
the uri too, so for example instead of a list<pair<string,string> > we
can return a generator function, an input iterator, a
multimap<string,string>, or a tuple.

> Note that the way the current parser works, it guarantees that if the
> URI is valid, the URI decoding can do with a lot less checks, I don't
> know whether this is a good idea though.
>

I don't understand what the concern is. Is there a problem you're
seeing with the current approach?

Also, please modify the patch to include your copyright information at
the top of the files you modify. :)

Thanks again!

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

Re: [cpp-netlib-devel] New Branch on Github

[Glyn M. <gly...@gm...>]

Hi,

2009/12/14 Dean Michael Berris <mik...@gm...>

> On Mon, Dec 14, 2009 at 9:16 PM, Glyn Matthews <gly...@gm...>
> wrote:
> >
> > 2009/12/14 Dean Michael Berris <mik...@gm...>
> >>
> >>
> >> Right. The request_header is definitely just a struct (or a POD). :)
> >
> > I think it's not a POD because it contains members that are of type
> > `std::string`.
> >
>
> Hmmm... That's odd. GCC 4.4 doesn't complain with the use case. I
> think this is still valid if it's not a POD because it allows for
> "static" initialization. I remember std::string can be statically
> initialized (as in, during compile time) which is why this works.
>

I'm not a language lawyer but as I understand it PODs have a trivial default
constructor, which doesn't apply to `std::string`.  But as you explain,
maybe you don't need it to be a POD to work.

>
> > I think nested classes could be a better approach, they will use the same
> > tags as the server class anyway.
> >
>
> I agree. However that would break code that's already using
> http::request for the client -- unless i typedef http::request to be
> by default http::basic_client<...>::request which is just ugly. That
> said, I think we can still afford to break backwards compatibility
> because, well, we're header only --  and breaking changes will cause
> users to actively upgrade their usage. <insert evil laughter here> :D
>
>
IMO, we shouldn't be afraid to break backwards compatibility at this stage
in development if the improvements are really valid.

Regards,
G

Re: [cpp-netlib-devel] New Branch on Github

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

On Tue, Dec 15, 2009 at 12:52 AM, Glyn Matthews <gly...@gm...> wrote:
>
> 2009/12/14 Dean Michael Berris <mik...@gm...>
>>
>>
>> Hmmm... That's odd. GCC 4.4 doesn't complain with the use case. I
>> think this is still valid if it's not a POD because it allows for
>> "static" initialization. I remember std::string can be statically
>> initialized (as in, during compile time) which is why this works.
>
> I'm not a language lawyer but as I understand it PODs have a trivial default
> constructor, which doesn't apply to `std::string`.  But as you explain,
> maybe you don't need it to be a POD to work.

Right. Not a language lawyer here too -- I trust what the compiler and
the tests say. Until I get my own copy of the C++ standard, I'll say
"if the tests say it's OK, then it should be OK". :)

>>
>> > I think nested classes could be a better approach, they will use the
>> > same
>> > tags as the server class anyway.
>> >
>>
>> I agree. However that would break code that's already using
>> http::request for the client -- unless i typedef http::request to be
>> by default http::basic_client<...>::request which is just ugly. That
>> said, I think we can still afford to break backwards compatibility
>> because, well, we're header only --  and breaking changes will cause
>> users to actively upgrade their usage. <insert evil laughter here> :D
>>
>
> IMO, we shouldn't be afraid to break backwards compatibility at this stage
> in development if the improvements are really valid.
>

Indeed. :)

> Regards,

Thanks! :D

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

Re: [cpp-netlib-devel] New Branch on Github

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

On Tue, Dec 15, 2009 at 2:42 AM, Dean Michael Berris
<mik...@gm...> wrote:
> On Tue, Dec 15, 2009 at 12:52 AM, Glyn Matthews <gly...@gm...> wrote:
>>
>>
>> IMO, we shouldn't be afraid to break backwards compatibility at this stage
>> in development if the improvements are really valid.
>>
>
> Indeed. :)
>

And this is done on 0.5-devel -- I'll just get some sleep and when I
wake I'll work on adding HTTPS support on both the client and the
server.

http://github.com/mikhailberis/cpp-netlib/commit/ec5996d260a9a506a59ecf4539dd4693a089b09a
is the commit that breaks backwards compatibility. The recommended
usage for the HTTP client now looks like:

  http::client client_;
  http::client::request request_("http://foo.bar/");
  http::client::response response_ = client_.get(request_);

On the server, it looks like this:

  struct foo {
    void log(...) {}
    void operator()(
      basic_request<tags::http_server> const & request_,
      basic_response<tags::http_server> & response_
    ) {
      // ...
    }
  };

  http::server<foo> foo_server;

Have a good day everyone, and I hope this helps!

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

Re: [cpp-netlib-devel] New Branch on Github

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

On Mon, Dec 14, 2009 at 17:45, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Jeroen,
>
> On Mon, Dec 14, 2009 at 9:12 PM, Jeroen Habraken <vex...@gm...> wrote:
>> On Mon, Dec 14, 2009 at 13:03, Dean Michael Berris
>> <mik...@gm...> wrote:
>>>
>>> Cool, please either fork the library on Github or send a git patch
>>> later on. I will be freezing the Subversion repository tomorrow.
>>>
>>> Have a good day!
>>>
>>
>> I've decided to roll an initial patch, please find it attached. It
>> fixes the following:
>> - stricter RFC compliant parsing of the scheme, in the generic URI
>> - It converts the scheme to lower case, as it states the following in
>> the RFC, "For resiliency, programs interpreting URI should treat upper
>> case letters as equivalent to lower case in scheme names"
>> - I've changes the parser of the port to use ushort_ and uint16_t, the
>> RFC specifies the port as *digit, but I think it should be limited to
>> the valid network ports, thus 0 <= port <= 2**16
>> - The query and fragment are now parsed conform to the RFC I believe,
>
> Thanks very much for this!
>
>> I'd like to change this later to parse the query into a
>> std::list<std::pair<string_type, string_type> >
>>
>
> I'd say a function that interprets the query part doesn't have to be
> part of the uri interface. I'd accept a function which would parse out
> the the .query() part of the uri into a
> list<pair<string_type,string_type> > that looks like this:
>
>  list<pair<string,string> > query_list_ = query_list(uri);
>
> This should be available via ADL and only for http uri's. The
> simplicity of the HttpUri concept should be preserved. Also, I'd
> imagine the query_list(...) function to dispatch to a specific
> implementation based on the tag associated with the uri. This is so
> that we can change the result type based on the tag associated with
> the uri too, so for example instead of a list<pair<string,string> > we
> can return a generator function, an input iterator, a
> multimap<string,string>, or a tuple.

This is indeed a better option, it keeps the URI parser relatively
simpler and prevents unnecessary work, whilst we still provide this
functionality, consider it on my TODO list.

>> Note that the way the current parser works, it guarantees that if the
>> URI is valid, the URI decoding can do with a lot less checks, I don't
>> know whether this is a good idea though.
>>
>
> I don't understand what the concern is. Is there a problem you're
> seeing with the current approach?

I should have been more clear here, normally when URI decoding a
string quite a few things can go wrong, imagine incorrect characters
'%2S', or it simply being too short, '%2'. A URI will not be parsed as
valid if such cases occur, making URI decoding relatively trivial as
you won't have to deal with such cases. We should provide a fully
functional uri_decode function though, capable of handling any input.
There actually turns out to be a fine implementation in the Boost.Asio
examples already, it's in
libs/asio/example/http/server/request_handler.cpp as url_decode.

> Also, please modify the patch to include your copyright information at
> the top of the files you modify. :)
>
> Thanks again!

You're most welcome. I've just created a github account, and think
forking the master and working from there is the easiest option.

Jeroen 'VeXocide' Habraken

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

Re: [cpp-netlib-devel] New Branch on Github

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

On Tue, Dec 15, 2009 at 3:26 AM, Jeroen Habraken <vex...@gm...> wrote:
> On Mon, Dec 14, 2009 at 17:45, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> I'd say a function that interprets the query part doesn't have to be
>> part of the uri interface. I'd accept a function which would parse out
>> the the .query() part of the uri into a
>> list<pair<string_type,string_type> > that looks like this:
>>
>>  list<pair<string,string> > query_list_ = query_list(uri);
>>
>> This should be available via ADL and only for http uri's. The
>> simplicity of the HttpUri concept should be preserved. Also, I'd
>> imagine the query_list(...) function to dispatch to a specific
>> implementation based on the tag associated with the uri. This is so
>> that we can change the result type based on the tag associated with
>> the uri too, so for example instead of a list<pair<string,string> > we
>> can return a generator function, an input iterator, a
>> multimap<string,string>, or a tuple.
>
> This is indeed a better option, it keeps the URI parser relatively
> simpler and prevents unnecessary work, whilst we still provide this
> functionality, consider it on my TODO list.
>

Cool. :)

>>
>> I don't understand what the concern is. Is there a problem you're
>> seeing with the current approach?
>
> I should have been more clear here, normally when URI decoding a
> string quite a few things can go wrong, imagine incorrect characters
> '%2S', or it simply being too short, '%2'. A URI will not be parsed as
> valid if such cases occur, making URI decoding relatively trivial as
> you won't have to deal with such cases. We should provide a fully
> functional uri_decode function though, capable of handling any input.
> There actually turns out to be a fine implementation in the Boost.Asio
> examples already, it's in
> libs/asio/example/http/server/request_handler.cpp as url_decode.
>

Right, but that is the reason why the query part of the parser was
very lax was that it should be externally dealt with through different
functions. Although the validity check as far as RFC strictness is
concerned is good, decoding the URI elements should be secondary to
the role of the parser which is supposed to just identify which part
of the URI is what.

I have been looking for a way of easily encoding and decoding URI's
with Boost.Spirit's Qi and Karma libraries. Maybe one day when I find
the need for that functionality I'll write it -- or if you want to
take on that implementation, then it should be something you can take
on as well. :D

>> Also, please modify the patch to include your copyright information at
>> the top of the files you modify. :)
>>
>> Thanks again!
>
> You're most welcome. I've just created a github account, and think
> forking the master and working from there is the easiest option.
>

Indeed. :)

Have a great day and week ahead!

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