package cohttp-lwt-unix

You can search for identifiers within the package.

in-package search v0.2.0

cohttp-lwt-unix
- Cohttp_lwt_unix
  - Client
  - Debug
  - IO
  - Net
    
    IO
  - Request
    
    IO
  - Response
    
    IO
  - Server
    
    IO

Legend:
Library
Module
Module type
Parameter
Class
Class type

The Client module implements the full UNIX HTTP client interface, including the UNIX-specific functions defined in C.

include Cohttp_lwt.S.Client with type ctx = Net.ctx

type ctx = Net.ctx

val call : 
  ?ctx:ctx ->
  ?headers:Cohttp.Header.t ->
  ?body:Cohttp_lwt.Body.t ->
  ?chunked:bool ->
  Cohttp.Code.meth ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

call ?ctx ?headers ?body ?chunked meth uri will resolve the uri to a concrete network endpoint using context ctx. It will then issue an HTTP request with method meth, adding request headers from headers if present. If a body is specified then that will be included with the request, using chunked encoding if chunked is true. The default is to disable chunked encoding for HTTP request bodies for compatibility reasons.

In most cases you should use the more specific helper calls in the interface rather than invoke this function directly. See head, get and post for some examples.

Depending on ctx, the library is able to send a simple HTTP request or an encrypted one with a secured protocol (such as TLS). Depending on how conduit is configured, ctx might initiate a secured connection with TLS (using ocaml-tls) or SSL (using ocaml-ssl), on *:443 or on the specified port by the user. If neitehr ocaml-tls or ocaml-ssl are installed on the system, cohttp/conduit tries the usual (*:80) or the specified port by the user in a non-secured way.

val head : 
  ?ctx:ctx ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  Cohttp.Response.t Lwt.t

val get : 
  ?ctx:ctx ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val delete : 
  ?ctx:ctx ->
  ?body:Cohttp_lwt.Body.t ->
  ?chunked:bool ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val post : 
  ?ctx:ctx ->
  ?body:Cohttp_lwt.Body.t ->
  ?chunked:bool ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val put : 
  ?ctx:ctx ->
  ?body:Cohttp_lwt.Body.t ->
  ?chunked:bool ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val patch : 
  ?ctx:ctx ->
  ?body:Cohttp_lwt.Body.t ->
  ?chunked:bool ->
  ?headers:Cohttp.Header.t ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val post_form : 
  ?ctx:ctx ->
  ?headers:Cohttp.Header.t ->
  params:(string * string list) list ->
  Uri.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt.t

val callv : 
  ?ctx:ctx ->
  Uri.t ->
  (Cohttp.Request.t * Cohttp_lwt.Body.t) Lwt_stream.t ->
  (Cohttp.Response.t * Cohttp_lwt.Body.t) Lwt_stream.t Lwt.t

val custom_ctx : 
  ?ctx:Conduit_lwt_unix.ctx ->
  ?resolver:Resolver_lwt.t ->
  unit ->
  ctx

custom_ctx ?ctx ?resolver () will return a context that is the same as the default_ctx, but with either the connection handling or resolution module overridden with ctx or resolver respectively. This is useful to supply a Conduit_lwt_unix.ctx with a custom source network interface, or a Resolver_lwt.t with a different name resolution strategy (for instance to override a hostname to point it to a Unix domain socket).