On Fri, Mar 6, 2020 at 1:00 PM Daniel Stenberg <dan...@haxx.se> wrote: > > On Fri, 6 Mar 2020, Jason Proctor via curl-library wrote: > > > Looking at the test case I think the issue is that I set CURLOPT_POST and > > provide neither CURLOPT_POSTFIELDS nor a read function. If the API contract > > says I have to do one or the other, fair enough - but should Curl survive if > > I don't? > > Without CURLOPT_POSTFIELDS (and *with* CURLOPT_POST set), libcurl only offers > one other way to provide the request body and that is the read callback. If > you don't set it, libcurl has a default read function that does an fread() by > stdin by default.
OK, confirmed that's the deal in my case. Typing control-D in the terminal window will unstick the library and it will call my header and write callbacks. I think it's reasonable for the command line tool to have a default reader which reads from stdin, as you're likely to want that, but for the library to do it seems a little unlibraryish :-) > What did you expect would happen? A zero byte body? Yes, I think I expected that saying I was doing a POST but not supplying any data would result in a zero byte body. > In my mind, CURLOPT_POST explains that you *either* use CURLOPT_POSTFIELDS or > a read callback and that there's no third option, but I'm certainly open for > that we need to extend or clarify the docs somewhere! OK, I violated the API contract. I think defaulting to an empty body in the library case is reasonable, but if you think that this is better off as a documentation fix, then fair enough. thanks for listening Jason@Spatial ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
