Tracking issue for httpaf support

[Anurag Soni]

The long lived httpaf pull request is not merged into a separate httpaf branch (https://github.com/rgrinberg/opium/tree/httpaf).

EDIT: The current master branch is now based on httpaf

This issue can be used to track problems with the implementation and changes needed before httpaf can be the default implementation used by opium.

@shonfeder Maybe you might be interested in this too.

• Add sexp derivers (Httpaf doesn't have sexp derivers for their types, consider using their pretty printers instead?)
• Add cookie module (will need something similar to Cohttp's cookie module)
• Support for SSL/tls (inhabitedtype/httpaf#131)
• Add streaming response support

[Thibaut Mattio]

Hi @anuragsoni!

Would you be interested in me helping out on the Cookie module?

If so, I am not sure if you've seen https://github.com/ulrikstrid/ocaml-cookie. It's a cookie implementation without any dependency on an HTTP library. They store the cookie as a list of key-value pair, which is the same representation as Httpaf, so it's easy to convert from one type to the other. I was thinking Opium could provide a thin layer on top of it to add/remove cookies from Rock Request/Response. What do you think?

[joseferben]

Hi @anuragsoni @tmattio

I have seen that @tmattio contributed the cookie module (thanks a lot!) by now. You listed SSL/TLS issue of httpaf, does that mean that the migration to httpaf can not be completed without it?

We really like the new API changes in opium_kernel and would like to base the web service of our framework Sihl on it. Currently we are using Opium with cohttp and a lot of custom API on top. What is needed for a release of opium_kernel?

[Thibaut Mattio]

Hi @Jerben!

Glad to hear you like the new API! The Cookie module is mostly copied from ocaml-cookie, so we have to thank @ulrikstrid for it 😄

I don't think the SSL support is a blocker: it seems to me that most people use their cloud provider's load balancer to provide the SSL layer anyways, so I don't think this would impact most users.

I'll let @anuragsoni and @rgrinberg propose a list of blockers for the next release. On my side, I'd say the following need to be done first:

• Upstream the Cookie module to ocaml-cookie
• Factor out the Rock module to a rock package and merge opium_kernel with opium

I also had a list of things I wanted to work on before the next release:

• Getting started documentation
• Rename Hmap0 to Context
• Provide a new API for the router
• Add a Session module with support for flash messages

However, they are not blockers, and some of them still need to be discussed, so we could cut a release without them.

[Ulrik Strid]

@tmattio if you're OK with it I can upstream your changes to ocaml-cookie. Just let me know if you want me to do it.

What is the router API you're thinking of? I've been wrapping @anuragsoni's excellent routes library in Morph

[Thibaut Mattio]

I'd also say, given the number of refactoring/additions to the code since the last release, I would like to improve the test coverage a bit before a release.

[joseferben]

Thanks a lot @ulrikstrid in this case too! 🙂

Extracting Rock sounds sensible, one step closer to have some common HTTP API. Where would the current middlewares go?

Regarding the router API, have you decided for an API already? I planned to implement something similar to the Plug inspired one that you posted on top of the Opium router:

let () =
  Router.scope
    ~middlewares:[ Middleware.require_auth ]
    ~route:"/users"
    router
    [ `POST, "/register", Handlers.register_user
    ; `POST, "/login", Handlers.login_user
    ]
```.

[Thibaut Mattio]

@tmattio if you're OK with it I can upstream your changes to ocaml-cookie. Just let me know if you want me to do it.

Sure! Since I changed the API, I wanted to get back to it and make sure the API made sense, but I didn't get the time to do it yet. If the API makes sense to you as-is, feel free to take the changes directly and I'll update opium's Cookie module.

What is the router API you're thinking of? I've been wrapping @anuragsoni's excellent routes library in Morph

See #150. There's no way to group a bunch of routes together and plug a list of middlewares to them. So route declarations in a large application can get messy...

[Thibaut Mattio]

@Jerben

Extracting Rock sounds sensible, one step closer to have some common HTTP API. Where would the current middlewares go?

We didn't figure all the details out yet. I think the first step will be to make a PR and we'll figure out that kind of thing during the code review. I'd say they should all go in opium, but that's just my opinion at the moment, we might decide to keep some of them in rock.

Regarding the router API, have you decided for an API already? I planned to implement something similar to the Plug inspired one that you posted on top of the Opium router:

I haven't, I'm not 100% satisfied with the example you took, but I haven't come up with a better solution 😕

[Anurag Soni]

I don't think the SSL support is a blocker: it seems to me that most people use their cloud provider's load balancer to provide the SSL layer anyways, so I don't think this would impact most users.

I agree with this. It might be nice to have it someday to get back to feature parity with the cohttp version, but i wouldn't hold this as a blocker for a release. The most common scenario i expect will be people running opium based app server behind another load balancer.

[Thibaut Mattio]

Since we agreed to release the Httpaf version and that SSL is not a major blocker, I think we can close this, and track the SSL support in a different issue.