Try using httpaf as backing http implementation

[anuragsoni]

@rgrinberg Just to start a discussion about using httpaf as the backing http implementation. This can be used to discuss gaps from current implementation. httpaf-lwt isn't published on opam yet, so people wanting to try this locally would need to use the pin-depends defined in the opam files in the PR.

On a sidenote: with a http2 implementation announces on discource yesterday (https://discuss.ocaml.org/t/ann-h2-an-http-2-implementation-for-ocaml/3578)

This pull-request could be rejected if the idea would be to have some sort of abstraction over that and httpaf so opium could be used with both HTTP1 and HTTP2

[rgrinberg]

Looks good to me. I'm definitely for this direction 👍

[anuragsoni]

@rgrinberg Once httpaf-lwt is published on opam i'll update the PR. We'd just need to fill in the static file server and the cookie handling that is done via Cohttp right now.

[anuragsoni]

Small update, this works with the httpaf packages published on opam now. The static file middleware is available now. Missing pieces:

• Sexp derivers (Httpaf doesn't have sexp derivers for their types)
• No cookie module (will need something similar to Cohttp's cookie module)
• No SSL/TLS (Client support for encryption inhabitedtype/httpaf#131)

[anuragsoni]

@rgrinberg One missing piece left is handling of Cookie headers. Not sure if we should add an implementation (similar implementation as what's present in Cohttp) as that seems like something that can be used independently of opium. Apart from that i''m also not sure we can do anything about the sexp derivers without upstream changes.

[Et7f3]

Some more thing to add in httpaf implementation
#96
websocket support (at least with one other libraries)

[anuragsoni]

Some more thing to add in httpaf implementation
#96
websocket support (at least with one other libraries)

https://github.com/inhabitedtype/websocketaf will be the candidate for the websocket support