trillion_exabyte has quit [Ping timeout: 246 seconds]
trillion_exabyte has joined #ocaml
mbuf has joined #ocaml
trev has joined #ocaml
Haudegen has joined #ocaml
azimut has quit [Ping timeout: 255 seconds]
bartholin has joined #ocaml
Haudegen has quit [Ping timeout: 255 seconds]
Haudegen has joined #ocaml
mro has joined #ocaml
Serpent7776 has joined #ocaml
trillion_exabyte has quit [Ping timeout: 255 seconds]
trillion_exabyte has joined #ocaml
<discocaml_>
<Et7f3 (@me on reply)> is incredible ? Is too cool ?
bartholin has quit [Quit: Leaving]
olle has joined #ocaml
kakadu has joined #ocaml
mbuf has quit [Ping timeout: 246 seconds]
maiste has joined #ocaml
maiste has quit [Quit: WeeChat 3.8]
azimut has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
wingsorc has quit [Ping timeout: 252 seconds]
bobo_ has quit [Quit: Konversation terminated!]
<discocaml_>
<cemerick> @companion_cube do you know of a good example for Ezcurl.post somewhere? I flailed around with it for too long last night; I was able to get it to send a multipart post, but couldn't figure out the incantation for a regular urlencoded form post.
<discocaml_>
<cemerick> Yeah, that usage produces multipart posts, right?
<discocaml_>
<val patate: unit Lazy.t> "is not enough like [ insert other language here ]
<discocaml_>
<val patate: unit Lazy.t> "is not enough like [ insert other language here ]"
<discocaml_>
<Et7f3 (@me on reply)> No this isn't true
<discocaml_>
<Et7f3 (@me on reply)> (Ok maybe rust super error message)
<discocaml_>
<cemerick> I actually tried that (pinning to the HEAD as well), and it could work (it's not a typical form post, but I could work with it since I control both ends of the HTTP call), but AFAICT any request that carries a body (via `~content`) hangs for almost a full second before being sent
<discocaml_>
<cemerick> (that's a separate problem I was going to file an issue on)
<discocaml_>
<cemerick> the same data plastered into the URL as part of the query string flows right through tho
<discocaml_>
<smondet> yes I think, sorry I don't really remember I didn't write that code 🙂
<discocaml_>
<cemerick> no worries, thanks for looking out 🙂
<discocaml_>
<Anurag> @cemerick Depending on the size of the body if it’s larger than some threshold curl sends a request indicating it’s waiting for a 100 continue header and waits for the server to acknowledge it before sending the body. There’s a timeout for this and if the server doesn’t acknowledge curl continues sending the body.
<discocaml_>
<Anurag> You could either have your server acknowledge this request and respond with an expect continue (or reject if you think the payload is too large) or disable this option in via curl options.
<discocaml_>
<Anurag> You could either have your server acknowledge this request and respond with an expect continue (or reject if you think the payload is too large) or disable this option on the client side via curl options.
<discocaml_>
<Anurag> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100> has some more details. I’d expect the request headers to confirm if this is indeed what’s happening. My guess is yes since I’ve also noticed a second long pause with curl in the past.
<discocaml_>
<cemerick> really! I've never heard of this. The payload in this case is in the hundreds of bytes tho, and the equivalent `curl` command line results in instant turnaround
<companion_cube>
@smondet would you be willing to add an example to the docs of ezcurl?
<discocaml_>
<cemerick> will check the headers tho
<companion_cube>
I'm not a curl expert and I use it more for get than other things
<companion_cube>
(and contributions welcome! 😁)
<discocaml_>
<Anurag> @cemerick hmm. 100s of bytes doesn’t sound too large so not sure about the delay in that case. I noticed it when the body was a few Megabytes. The 100-continue thing was news to me at that time as well!
<discocaml_>
<cemerick> Yes, `curl` command line sends no `Expect` header, ezcurl by default does, for any request that carries a body
<discocaml_>
<cemerick> I shall dig around for the requisite config flag
<discocaml_>
<Anurag> Cool. That makes sense! That header explains the delay you see. None of the OCaml http server libraries handle this scenario from what I remember, so your best bet will be to update the client settings.
<discocaml_>
<cemerick> Okay, the canonical workaround for the expect thing is to set an empty Expect header, i.e. `~headers:["Expect", ""]` with Ezcurl; there is a configuration setting for libcurl (`EXPECT_100_THRESHOLD`), but it doesn't seem to be exposed by ocurl