Tls_lwt: delay error from writing to peer while reading.#388
Conversation
|
@hannesm thanks for putting this together. I've tested this in my repro and it fixes the issue I was seeing. |
|
With this patch i'm still getting |
|
@rymdhund hmm, strange. I tested your example server and the provided lwt/examples/http_client.ml -- and I see the following (stripped) output: note that I'm using cohttp* pinned to git+https://github.com/mirage/ocaml-cohttp.git, conduit* pinned to git+https://github.com/avsm/ocaml-conduit.git#ipaddr-3 (see mirage/ocaml-conduit#284) I also tested with a fresh switch and only released packages (not even using this PR), which resulted in no exception, but the same behaviour as above. any chance an |
|
@hannesm that is strange! I'm getting the problem with exactly the same opam list as you. Perhaps your pinned conduit or cohttp changes the behaviour of the server somehow? Here's a dockerfile that replicates my problem. Building and running it will give you the |
|
@rymdhund thanks. the list of opam packages above does not use any pins, only released packages (I installed this into a different switch). I'm testing on FreeBSD system (no Do you have the same conduit and cohttp versions installed as I have (in the above opam output)? Which ocaml version do you use? |
|
@hannesm great! That fixed my issue :) |
previously, if handle_tls returned a response to the peer, write was called, which may error out (recording it's error in the state and Lwt.fail). the received data was never returned to the caller. now, similar to the semantics in tls_mirage, the error from write is only recorded in the state, and returned on the next function call (write/..).
this ensures proper Lwt_io interoperability, esp. if an Eof has been received, which in the TLS world is replied to with a close_notify alert -- this write can certainly fail. earlier, this resulted in an `Error state, now the `Eof state is retained and Lwt_io can read all application data.
d1eda58 to
c36c66f
Compare
Since tls 0.9.3, the specific issue (error after eof) has been fixed. See mirleft/ocaml-tls#388 for the applied fix.
previously, if handle_tls returned a response to the peer, write was called,
which may error out (recording it's error in the state and Lwt.fail). the
received data was never returned to the caller.
now, similar to the semantics in tls_mirage, the error from write is only
recorded in the state, and returned on the next function call (write/..).
should fix #347, alternative to #371, #387 -- could you please test this @edwintorok @anmonteiro @rymdhund //cc @pqwy