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

[John P. F. <jf...@ov...>]

Dean Michael Berris wrote:
> 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.
>   
To be truthful I haven't even bothered to determine that. Spirit 2 was 
and still is for me- ambiguous. I simply chose to base that work off the 
boost_139 spirit docs.

> 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.
>
>   
That seems rational. Actually, after a stint of researching some Java 
and Python based networking libraries, I myself have come the conclusion 
that presenting the user with a configurable connection object for a 
particular protocol is preferred, in addition to a client facade for 
common use-cases. As a side note, I have also come to the conclusion 
that a mailing list is not my preferred forum for this sort of 
discussion, which is better suited by collaborative specifications and 
conferencing. I'm curious as to what the opinions of the other 
developers are on this.

John