cirocosta / yahttp-parser

A naive C++ HTTP parser implementation using Bison and Flex

yahttp-parser

A naive C++ HTTP parser implementation using Bison and Flex

ATTENTION: this is NOT a full spec conformant parser. It DOES NOT aim to comply with all of the requirements associated with the roles it partakes in the HTTP specification.

Install

Make sure that you have all the dependencies installed:

• flex
• bison*
• make
• cmake
• a modern c++ compiler - targetting c++11 (i recommend clang, 3.5 is good)

Then, simply:

$ mkdir build
$ cd build
$ cmake ..
$ make && make test

*: If you've built bison from source and in the make step it claims that there's a problem with m4, try setting the pkgdata_dir:

export BISON_PKGDATADIR=/usr/local/share/bison/data

CMake

yahtml-parser_INCLUDES  : include directories
yahtml-parser_LIBS      : libs to link against

HTTP 1.1

If you wish to get in touch with the spec, take a look at

• RFC7230 - HTTP/1.1: Message Syntax and Routing - low-level message parsing and connection management
• RFC7231 - HTTP/1.1: Semantics and Content - methods, status codes and headers
• RFC7232 - HTTP/1.1: Conditional Requests - e.g., If-Modified-Since
• RFC7233 - HTTP/1.1: Range Requests - getting partial content
• RFC7234 - HTTP/1.1: Caching - browser and intermediary caches
• RFC7235 - HTTP/1.1: Authentication - a framework for HTTP authentication

(see RFC2616 is Dead)

LICENSE

GPLv2

yahttp-parser's Issues

make tests off by default

those who depends on the module don't need to always build the tests

namespace

wrap everything in a well suited namespace (including the scanner and parser)

using

body

multiple headers values for same key

It's common to have something like:

Connection: keep-alive
Connection: Transfer-Encoding
Set-Cookie: _locale=pt_BR; expires=Mon, 24-Aug-2015 12:58:32 GMT; path=/; domain=lol
Set-Cookie: _hue=brrbr; expires=Mon, 24-Aug-2015 12:58:32 GMT; path=/; domain=lol

don't know if we should proceed with a ::map<std::string, std::vector<std::string>> structure for headers ..

by the time only the last remains in the mapping.

---

Spec:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

Note: In practice, the "Set-Cookie" header field ([RFC6265]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of [Kri2001] for details.)

So, maybe we could stay with ::map<std::string, std::string> and attain to the spec: in case of collision, append w/ comma. As we don't really care about cookies this might suffice.

cmake

static http version string

simplify parser interface with stringstream

we can take advantage of move semantics and then reduce the amount of string conversions that are going on

CI

travis-ci

• gtest ( #7 )
• mem leaks w/ valgrind (#8)

gtest

after setting #2