[cpp-netlib-devel] URL Library work for Sponsored HTTPS Development

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

Hi Guys,

As some of you have known there's a former client of mine that's
interested in sponsoring the HTTPS development support to be put into
cpp-netlib. He has indicated that he's willing to give a fixed amount
($600) the last time we had correspondence. This requirement is a
real-life requirement, and I'd think it's a good test for the
cpp-netlib developers community. Having said this, I've already gotten
"yes" responses from some contributors. Here's my plan:

 - Develop HTTPS functionality
 - Contributors that contribute will get part of the money (I will
have none of it). Valid contributions come in the form of:
  * Tests
  * Examples
  * Documentation
  * Code
  * Bug reports & testing

What I have decided too is that I will most probably add some more to
the "fund" in case I find that the number of contributors exceeds my
expectations.

At any rate, I've started the implementation of a simple URL parsing
library that's uses Boost.Spirit 2.x (in boost trunk) instead of
Boost.Spirit Classic. I think there's work to be done to port the code
that's in the http_integration branch to Boost.Spirit 2, and I'm happy
to delegate that work whoever wants to pick that up.

The work I've done is in
https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/urllib-dean/
-- please check it out and help out with the implementation for other
protocols using the HTTP example as a guide. I'm looking at supporting
the protocols defined in RFC 1738.

Once we have this URL library able to parse the 'https' from the
string provided (which is already done albeit doesn't support
uppercase characters yet) in the url constructor, then we can commence
on breaking up the HTTP client to support HTTPS. To do this, we need
to make the connection object dynamic (runtime dynamic, yes,
unfortunately :| ) so that we can define the per-connection setting
whether we do SSL or normal TCP or in the future SCTP if it's
available in Boost.Asio based on the URL provided to the constructed
HTTP message.

Another vector of work will be to make the http_message implementation
use the boost::network::url::http_url type instead of a normal string.

More from me tomorrow or some other day, but for now I will
concentrate on getting this URL library working better and fully
supporting the specifications for HTTP.

Questions, comments, clarifications, suggestions, and reactions most welcome. :)

(Sorry it's been a while, between getting married, moving jobs, and
being swamped, I haven't been able to get much done for this library.
Hopefully this is a start in the right direction for me and this
library. :D)

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