I'm not sure what issue the OP is referring to, but I had at first problems with CURLOPT_POSTFIELDS, since at least curl PHP binding documentation does not mention that setting CURLOPT_POSTFIELDS implies CURLOPT_POST and I didn't realize that first.
My usage pattern was that I was setting most of states since I was recycling curl handle, but unluckily I happened to set POSTFIELDS after POST/GET state... If I could choose, I would actually prefer that no option implies any other option. But that would probably break insane amount of code using libcurl so probably better just emphasize stuff in the documentation. Regards, Jani On Sun, Dec 27, 2009 at 4:17 AM, Daniel Stenberg <[email protected]> wrote: > On Sat, 26 Dec 2009, [email protected] wrote: > > So it seems that it would be quite valuable if the documentation were as >> clear as the source comment is about the side-effects of setting POSTFIELDS. >> And as there are a few other similar side-effects to setting other options, >> it would be helpful to document those as well. >> > > What comment are you referring to? What libcurl version are you using? > > In current libcurl, CURLOPT_POSTFIELDS set (to anything) implies a POST. > Thus if you set POSTFIELDS to NULL _after_ setting HTTPGET to 1, it still > will end up in a POST. > > I don't see anything in the docs that says setting POSTFIELDS to NULL is a > good idea if you don't want to send a POST. > > So, can you please tell us exactly how you suggest we alter/change the docs > to make the behavior better described? > > -- > > / daniel.haxx.se > > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html >
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
