-
Notifications
You must be signed in to change notification settings - Fork 174
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
SSL read() error while reading response from a POST request #999
Comments
Which version of cohttp are you using? If you install |
Hi @mseri thanks for looking into it - I'm using cohttp 5.0.0. It's not easy for me to try |
It is absolutely supported. I was asking to check if using a different stack was working, and if not hopefully get a more informative error. It is hard for me to debug this problem without knowing if the issue is in cohttp, conduit, lwt, the c bindings or somewhere else |
Fwiw the only similar error that I know is #980 in that case the same suggestion helped pinpointing the issue |
Sorry @mseri for the delay in responding. I have tried to get you some more information to help identify the issue. Here's the relevant snippet of the output of
As you can see it's the 3rd The stack trace that leads to that system call (and also the others probably) is as follows:
The "workaround" I'm using for now is to implement my own let body_to_string = function
| #Cohttp.Body.t as body -> Lwt.return @@ Cohttp.Body.to_string body
| `Stream s ->
let s = Lwt_stream.wrap_exn s in
let b = Buffer.create 1024 in
let+ () =
try
Lwt_stream.iter
(function
| Ok x -> Buffer.add_string b x
| Error e -> raise e )
s
with e ->
Log.trace
"Exception while processing http stream: %s"
(Printexc.to_string e)
|> Lwt.return
in
Buffer.contents b Instead of the original implementation: https://github.com/mirage/ocaml-cohttp/blob/master/cohttp-lwt/src/body.ml#L45 This is unsatisfactory of course, as it masks an actual error by assuming it means "end of stream". Please let me know if there's more debugging information I can collect for you. I am also trying to read through the source code of some of the packages involved to see if I can come up with a hypothesis - the C bindings looked pretty halal to me. |
I could not see where we are miscalculating the size. So far I am suspecting that this is really an issue with the server (also because error 00000000, if I understood openssl documentation correctly, means no error). I think python and curl are not failing because by default the ignore premature end of file errors, something that we cannot yet do in ocaml-ssl. If you can pin ocaml-ssl to a custom version and edit the code to set https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html#SSL_OP_IGNORE_UNEXPECTED_EOF we could check if this resolves the issue |
Thanks @mseri - the size miscalculation is just speculation on my part. Your theory sounds a lot more plausible - I should be able to try a modified |
Hi @mseri - sorry for the delay, I finally got some time to look into this. I used a modified version of |
Seems like the correct place, but I would not bet on it, I don't know the innards of ocaml-ssl. |
Hello, I am encountering a strange error and would like to know if the authors can help.
I am trying to get a token from an OAuth2 server using a POST request. This request succeeds using
curl
or a python implementation using therequests
library.But when I use
Cohttp_lwt_unix.Client
, while the status code is 200, the extraction of the`Stream
fromCohttp_lwt.Body.t
, usingCohttp_lwt.Body.to_string
fails with this error:The google brought me to this issue on the curl repo: curl/curl#1689
This suggests that it's a problem with the server - but the server works fine with curl and python and even returns a successful status code, so it makes me wonder whether this is something peculiar with the
Cohttp
implementation (specifically theTransfer*
modules).Unfortunately I do not have a way for you to replicate the error, but I'm hoping someone has seen this before or can spot an obvious cause of this error.
Thank you!
The text was updated successfully, but these errors were encountered: