
I'm sorry for taking so long to present my proposal, but some unpredictable events delayed the available time I had to work on the proposal and the large number of mentions you guys made turned my work into a task more difficult. Anyway, like some people advocating on open source projects state, "release early, release often". Then I'll post the link to the incomplete proposal through github, then I'll have a nicely formatted MarkDown file and you guys can easily use the diff button on the web interface to see the changes: https://github.com/vinipsmaker/gsoc2014-boost Em Qui, 2014-03-06 às 11:28 -0600, Cory Nelson escreveu:
Making a good, correct HTTP 1.1 parser is very non-trivial -- this is actually a pretty ambitious project for GSOC. I'd recommend condensing your idea as much as possible and working on it in cleanly separable steps. Don't get distracted by Websockets and FastCGI!
I haven't said anything about timelines yet. I want to have a clear core library and then move on to measure/guess what can be implemented during the GSoC and define the timeline.
Please make the parser I/O agnostic and non-blocking (push bytes in, get a chunk of a http message as a result or request for more data) -- it'll be simpler to test and will allow porting to lower-level I/O when asio becomes too slow.
About the parser, it's less useful for people than an actual http server. I was planning to initially use Ryan Dahl's HTTP parser, then I can focus on imediate needs. A parser with a good interface could be provided in the future. But... I'm too late and Vinnie Falco just suggested the same: Em Qui, 2014-03-06 às 09:44 -0800, Vinnie Falco escreveu:
These are good guidelines. Let me point out that the HTTP parser from node.js is permissively licensed, and incredibly robust:
https://github.com/joyent/http-parser
It's hardened and battle-tested so there are no exploits in it. I use it in my own HTTP message wrapper and handshaking logic. Instead of writing one yourself, I highly recommend that you instead take this http-parser as is and put a boost-worthy C++ front end around it.
The problem with the Ryan Dahl's HTTP parser is that it doesn't support arbitrary HTTP methods/verbs. Then it should be replaced in the future. Em Sex, 2014-03-07 às 10:00 +1100, Dean Michael Berris escreveu:
[...] However as mentioned if someone would like to take cpp-netlib's 0.11.0 version and turn it into a proper Boost.Network library, I'm more than happy to make myself available for Hangouts to get the process going as quickly as possible.
The scope of the cpp-netlib is quite large. I'd like to focus on the HTTP server abstraction. But thanks for the support anyway, Dean. I might bug you for questions regarding the cpp-netlib's design. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker