-
Notifications
You must be signed in to change notification settings - Fork 74
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
Do not close connection after read #280
Comments
So I tried to retranslate your code with the new version of open Lwt.Infix
let () = Mirage_crypto_rng_unix.initialize ()
let load_file filename =
let ic = open_in filename in
let ln = in_channel_length ic in
let rs = Bytes.create ln in
really_input ic rs 0 ln ;
close_in ic ;
Cstruct.of_bytes rs
let config cert key =
let cert = load_file cert in
let key = load_file key in
match
(X509.Certificate.decode_pem_multiple cert, X509.Private_key.decode_pem key)
with
| Ok certs, Ok (`RSA key) ->
Tls.Config.server ~certificates:(`Single (certs, key)) ()
| _ -> invalid_arg "Invalid key or certificate"
let tls_config = config "server.pem" "server.key"
let tcp_config =
{ Conduit_lwt.TCP.sockaddr= Unix.(ADDR_INET (inet_addr_loopback, 19979))
; capacity= 40 }
let handler flow =
let flow = Conduit_lwt.pack Conduit_lwt_tls.TCP.protocol flow in
let ic, oc = Conduit_lwt.io_of_flow flow in
Lwt_log_core.notice "Server: Callback started." >>= fun () ->
Lwt_io.read ~count:255 ic >>= fun msg ->
Lwt_io.printf "got data %s" msg
let fiber =
let _stop, run = Conduit_lwt.serve
~handler ~service:Conduit_lwt_tls.TCP.service (tcp_config, tls_config) in
run
let () = Lwt_main.run (fiber ()) compilation & run with: $ ocamlfind opt -linkpkg -thread -package conduit-lwt-tls,conduit-lwt,lwt_log.core,mirage-crypto-rng.unix -o a.out main.ml`
$ ./a.out client side: $ openssl s_client -connect 127.0.0.1:19979
foobar
The connection is not close I consider this issue as closed but if you want to precise your expected behavior, feel free to re-open the issue and we will see what we should do then. |
Now the situation reversed from #274
now netcatting into the server ALWAYS results in a server close
The text was updated successfully, but these errors were encountered: