Populate headers for HTTP OPTIONS requests

[DavidPetkovsek]

When running middleware for an HTTP OPTIONS request (for CORS for example). There is a bug where the headers from the request are not populated. Also referenced here: #721 (comment).

The reason this occurs is because the parser will parse the URL first (before the headers) and in the handle_url function, it will end parsing the request early, returning the response, and triggering the middleware.

The proposed changes will prevent us from exiting early in the handle_url function and instead exit early at the handle_headers function, which is executed when all of the headers have finished parsing.

It is also important to note that OPTIONS requests are fully handled within crow, and crow will never call a user defined OPTIONS route.

I believe this Fixes #721.

[gittiver]

The automatic test seems to hang somewhere, all automatic builds are stopped there without finishing the test.

[DavidPetkovsek]

The automatic test seems to hang somewhere, all automatic builds are stopped there without finishing the test.

It is hanging on

Crow/tests/unittest.cpp

Line 2047 in 584560f

resp = HttpClient::request(LOCALHOST_ADDRESS, port,

Which is testing an invalid HTTP packet. Causing the parser to report an error to do_read() here

Crow/include/crow/http_connection.h

Line 492 in 584560f

CROW_LOG_DEBUG << self << " from read(1) with description: \"" << http_errno_description(static_cast<http_errno>(self->parser_.http_errno)) << '\"';

Which hangs.

The unit test never hang before because the OPTIONS packet would stop parsing early at the url stage.

---

From reading the unit tests file I believe this unit test was not designed to test an invalid packet. Correcting the packet causes that specific unit test to no longer hang.

That being said, now one of the tests fail, so I will work on that.

[DavidPetkovsek]

Turns out it was the same thing as the previous comment. The unit test in question was failing because the result it was getting was empty. It was empty because an error was thrown ( stream ended at an unexpected time ) due to an malformed packet. Correcting the packet causes the unit test to no longer error and now pass.

The unit test never failed before because the OPTIONS packet would stop parsing early at the url stage.

[DavidPetkovsek]

@gittiver I believe this is ready for your review once again. :)

[DavidPetkovsek]

^ rebased onto master