Provide info about underlying connection in Request

[little-arhat]

In some cases one may want to access info about underlying connection in request handler function, such as ip address of peer, local port.

There is no obvious way to do so currently.

It would be nice to have such features in cohttp.

[little-arhat]

One may want to access underlying connection, to set socket options, also. That might be useful for implementing http-streaming services, for example.

[avsm]

This is exposed in Cohttp_lwt_unix in 0.12.0+ (see e015f79 for an example)

[little-arhat]

But I'm using mirage and my http server is Cohttp_lwt.Server. Is it possible to access underlying connection it this case? Or at least local client ip?

[avsm]

That's a critical bit of useful information :-)

The Conduit_mirage API will have similar functionality, but isn't quite complete yet -- it's very close though. Do file bug reports or pull reqs to expose functionality that you need in the meanwhile.

On 3 Nov 2014, at 10:59, Roma Sokolov [email protected] wrote:

But I'm using mirage and my http server is Cohttp_lwt.Server. Is it possible to access underlying connection it this case? Or at least local client ip?

— Reply to this email directly or view it on GitHub https://github.com/mirage/ocaml-cohttp/issues/188#issuecomment-61463110.

[dinosaure]

May be you want this ?

[little-arhat]

@dinosaure yes, this function might be useful, but when I'm using mirage to create http-service, my http-callback function has this signature: H.IO.conn * Cohttp.Connection.t -> Cohttp.Request.t -> Cohttp_lwt_body.t -> (Cohttp.Response.t * Cohttp_lwt_body.t) Lwt.t, so I cann't use Conduit_lwt_unix on it: Type Conduit_lwt_unix.flow is not compatible with type H.IO.conn.

https://github.com/mirage/mirage-http/blob/master/lib/HTTP_IO.mli

[avsm]

You definitely can't use Lwt_unix there -- the idea is that the Cohttp_* backend exposes the right type equivalence for conn depending on the backend. In the case of the unix backend, this was done in 255b8b01b3afa30cc94f624132a507e7d45aaa06 -- a similar patch is probably needed for mirage

On 3 Nov 2014, at 14:02, Roma Sokolov [email protected] wrote:

@dinosaure https://github.com/dinosaure yes, this function might be useful, but when I'm using mirage to create http-service, my http-callback function has this signature: H.IO.conn * Cohttp.Connection.t -> Cohttp.Request.t -> Cohttp_lwt_body.t -> (Cohttp.Response.t * Cohttp_lwt_body.t) Lwt.t, so I cann't use Conduit_lwt_unix on it: Type Conduit_lwt_unix.flow is not compatible with type H.IO.conn.

https://github.com/mirage/mirage-http/blob/master/lib/HTTP_IO.mli https://github.com/mirage/mirage-http/blob/master/lib/HTTP_IO.mli — Reply to this email directly or view it on GitHub https://github.com/mirage/ocaml-cohttp/issues/188#issuecomment-61480845.

[gasche]

Two more people have asked about this feature on the #ocaml IRC channel yesterday, Algebr and @AltGr .

[yomimono]

One more person has asked about this feature on the issue tracker today, and it's me. I want to implement some rate-limiting per remote IP for a MirageOS unikernel webserver, and if my type archaeology is correct, that's still not possible. :cry:

[mseri]

Yes. This is still not possible. If I recall correctly this would need some changes at conduit level. We are breaking some apis, any contribution is welcome

[paurkedal]

Make that +1. My use case is a unikernel which issues unvalidated certificates, merely identified by serial number. It primarily meant for CIs or other throw-away environments, though it would be nice if it could validate source IP or domain name.

[yomimono]

It seems like some relevant discussion is in https://github.com/mirage/ocaml-cohttp/issues/779 ("cohttp API 4 questions") but it's rather divorced from what I think is also an ongoing conversation in https://github.com/mirage/ocaml-cohttp/issues/821 ("Conduit Free Servers") , and I know there's additional context around MirageOS 4.0 and the future of web server invocation there.

I don't have my head enough in the game to make a concrete suggestion -- I already missed my chance to fix this once! But big refactors are a good time to make sure your wheel squeaks enough not to be forgotten, even if it is more annoying noise for maintainers who hear nothing but wheel squeaks all day :/

[mseri]

@rgrinberg do you have an idea on how to address this in a clean way?

[hannesm]

I'm neither @rgrinberg nor do I know what a clean way would be, but one possibility is https://github.com/roburio/ocaml-conduit/tree/client-ip4 and https://github.com/roburio/ocaml-cohttp/tree/client-ip4 (that's on top of the 4.0 release). This breaks the API, but has been shown useful for my use cases.

[dinosaure]

On the other side, I'm not sure that the usage of conduit is relevant for the server part. For instance, paf provides the underlying flow used to communicate with clients.