The API supports both synchronous and asynchronous modes of operation. This is fine, and will remain. The implementation, however, has three separate modes of operation when reading / writing to the underlying socket: 1) blocking, 2) non-blocking, and 3) asynchronous. These modes are currently necessary as the HTTP/1.1 implementation is blocking ( the request is sent blocking, socket switched to non-blocking and registered with a selector, upon read-ready switched back to blocking and the response is read blocking ). The HTTP/2 implementation is completely async. The blocking mode causes a proliferation of connection types as well as duplication of all code connected with reading and writing. This is further complicated as connections may start off as HTTP/1.1 and then be upgraded to HTTP/2, thus requiring switching out the connection type and protocol coder / decoder. A "fake" HTTP/1.1 initial upgrade request cannot be made as 1) the connection may not actually be upgraded, and 2) redirection, authentication, proxying support, is required at this point ( do not want to duplicate this ).

A single execution mode ( event-driven non-blocking ) in the implementation will significantly reduce the amount of code, while increasing the common machinery that can be shared across HTTP/1.1 and HTTP/2. The synchronous mode of operation in the API will be implemented trivially as a join on an async call.

Note: since HTTP/1.1 is currently implemented as blocking, there is no non-blocking support for parsing headers or chunked encoding. This will be needed before HTTP/1.1 can be made async.