Open HTTP Design Problems

[vinniefalco]

"Sans-Asio" : a public API that has no Asio in it

• Setting the response body in the route_params via buffers::any_source
• Receiving the request body in the route_params via buffers::any_sink
• any_stream - a universal stream supporting ipv4, ipv6, unix domain, SSL
• strong asio coroutine story body_read_stream, body_write_stream
• high level HTTP client
• shared settings in parser, serializer
• passing objects (e.g. json::value) to chained handlers: route_params route_data and session_data
• OPTIONS * and options in general (methods from routes, accept-encodings)
• templating engine: handlebars, Jinja, or similar
• Return error responses: only possible if nothing is serialized yet
• worker / workers constructor parameter lists are opaque / hard to read
• route pattern params / match struct in basic_router.cpp, e.g. "/rpc/:id/call"
• HTML algorithms: escaping, generating pages, and such
• Utilities like base16, base64, SHA1
• Should Boost.Http have Boost.JSON as a dependency?

[vinniefalco]

Ruben's proof of concept https://gist.github.com/anarthal/665272e1a5be3cb8813d3d35ac3b0ee9

[vinniefalco]

JSON-RPC concepts
https://gist.github.com/vinniefalco/36344fc29b77fc4594aee39ffbe8285a

[vinniefalco]

Life of a URLRequest
https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/life-of-a-url-request.md

[MungoG]

As it offers better tracking tools, I have put all of these items into a new Github Project: https://github.com/orgs/cppalliance/projects/8/views/7

Note: It is not possible to link a Github Discussion from a Github Project (which is annoying but it is not a feature Github offers) so I had to create issues for each of these items.