Re: [cpp-netlib-devel] Help! Grammar for parsing HTTP URLs

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

Hey John!

On Sun, Aug 16, 2009 at 6:26 PM, John P. Feltz<jf...@ov...> wrote:
> Sorry to chime in late as always,

No worries, better late than never. ;-)

>
> I just dumped the in-progress work that I was doing into
> http_integration_jf. This was done a number of months ago, prior to my
> life-forcing break from this project. The only thing that is functional
> -is the uri parser. This spirit implementation is inspired from Braden
> McDaniel's uri-grammar. The gist of the design is that there was a main
> class which did structural grammar checking of the url, and then a
> family of re-usable grammar classes which corresponded to the http
> components. To see this in action: build the tests under
> libs/uri/test.For now I hope this lends some insight. I should get
> around to cleaning this branch up in the near future.
>

Cool! Are you using Boost.Spirit 2x? I haven't been looking at these
changes closely.

What I've already started doing is have a base URL class from which
all specific URL families (HTTP, FTP, etc.) will derive from. I've
based my implementation on RFC 1738. There's a two-step parsing
approach I use which first does a generic parse that parses the scheme
from the scheme specific part; then invokes a 'parse_special' function
that parses the scheme specific part.

The basic_url<tags::default_> implementation is a bare basic_url<>
that just supports the protocol(...) and rest(...) function. The
specialization of the basic_url<...> for the HTTP urls is
basic_url<tags::http> -- and the parsing specific to HTTP URLs is
encapsulated in parse_special<traits::string<tags::http>::type,
tags::http>(...). This allows anyone to create a specialization of
basic_url<...> for the special parsing of FTP, "mailto", etc.

Maybe we can merge the work together in a branch just for the URL
parsing, then make the http_message implementation use the new URL
library instead of the adhoc implementation that it's using at the
moment? Personally I really want to be using Spirit 2x because I also
intend to use Karma for the HTTP Message generation/encoding for MIME
messages.

Of course that's a lot of work down the road, but the current
(not-so-well-tested) implementation seems to be able to identify
between HTTP and HTTPS ports. From there we should be able to write
the stuff that allows the HTTP client to create its own connections
based on the protocol(http_message.url()) -- if it's "https" then use
the ssl::socket and if it's just "http" use the normal tcp::socket.
That needs to be ironed out and refactored into a separate logic for
connection handling.

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