felipealmeida / http-parsers

HTTP parsers
2 stars 1 forks source link

Features #1

Open vinipsmaker opened 10 years ago

vinipsmaker commented 10 years ago

The parser should consume a few headers, then it won't need to revisit them and it'll be able to continue parsing:

The parser shouldn't need to keep any byte buffered once the byte is parsed.

It should be possible to reset the parser at anytime.

The parser should be configurable (via traits?), then we could define things like:

felipealmeida commented 10 years ago

Hello @vinipsmaker

The idea here on the parsers is that it is written as unified grammars. The parsing algorithm would consist of inputing this grammar and the range of iterators of the data and save the structured information in a heterogeneous sequence (e.g, a fusion sequence).

Also, with the same grammar we would have the code to generate the MIME headers (and etc) using the same grammar while receiving the heterogeneous sequence and a output iterator where the formatted data is written.

Do you have needs bigger than just header parsing I imagine right? What would be those (e.g., http chunking) ?

vinipsmaker commented 10 years ago

Do you have needs bigger than just header parsing I imagine right? What would be those (e.g., http chunking) ? A little more, yes. Finding the beginning and the end of the body (with HTTP pipelining support).

And definitively a MUST is to support resuming partially received messages. It's a networked environment, after all.

The parsing algorithm would consist of inputing this grammar and the range of iterators of the data and save the structured information in a heterogeneous sequence (e.g, a fusion sequence).

Can you expand on that? How much control will the user maintain?