Re: CURLOPT_POST with no CURLOPT_POSTFIELDS

On Fri, Mar 6, 2020 at 1:00 PM Daniel Stenberg <daniel_at_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_at_Spatial
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-03-07