New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make server response type abstract and allow streaming in cohttp-eio #1024
base: master
Are you sure you want to change the base?
Conversation
This will allow cohttp-eio to use a different type in future, which should make streaming easier.
Makes next commit easier to read: - Use `respond` helpers in example. Avoids it having to change. - Remove useless `IO.t` and `>>=`. - Move some functions later in the file, and they'll need to use `write`.
Looks good to me! I would even suggest making We might even make val respond :
?headers:Http.Header.t ->
?flush:bool ->
?status:Http.Status.t ->
_ Eio.Flow.source ->
response IO.t So that the simplest form becomes |
That probably is a better API, but it's trying to implement the signatures in the shared cohttp package, so they would have to be extra functions with different names if we did that. Maybe something for a separate PR? |
This changes the response type to `writer -> unit`. This allows handlers to write the response inside the function, rather than returning a request to cohttp to write it later. That's useful because it allows e.g. streaming from an open file and then closing it afterwards. Partial application means that code using `respond_string` etc will continue to work as before. This also exposes a more polymorphic version of the `respond` function that accepts sub-types of `Flow.source`, so that callers don't need to cast the body.
ebdbff2
to
34f881c
Compare
|
||
type t = { | ||
conn_closed : conn -> unit; | ||
handler : conn -> Http.Request.t -> body -> response_action IO.t; | ||
handler : conn -> Http.Request.t -> body -> IO.ic -> IO.oc -> unit; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern is that the change to old-style response was done to align the APIs, with this they APIs are diverging again (at least in the expectations and signatures)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, although not when using the normal response functions. So it's certainly possible to write code that works with both.
Co-authored-by: Marcello Seri <mseri@users.noreply.github.com>
This fixes #998.
The first commit adds an abstract
response
type and then usestype response = Http.Response.t * Body.t
in cohttp-lwt and cohttp-eio to keep the final types the same (cohttp-async already defined this type anyway and so didn't need any updates).The second is just a few trivial changes to cohttp-eio to make the third commit diff smaller.
The third commit changes the
response
type in cohttp-eio totype response = writer -> unit
. This allowshandlers to write the response inside the function, rather than returning a request to cohttp to write it later. That's useful because it allows e.g. streaming from an open file and then closing it afterwards.
Partial application means that code using
respond_string
etc will continue to work as before.This also exposes a more polymorphic version of the
respond
function that accepts sub-types ofFlow.source
, so that callers don't need to cast the body./cc @mefyl