cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Impossible to POST binary data with CURLOPT_POSTFIELDS

From: Spacen Jasset <spacenjasset_at_yahoo.co.uk>
Date: Fri, 12 Oct 2007 02:37:14 +0100

Dan Fandrich wrote:
> On Fri, Oct 12, 2007 at 12:04:58AM +0100, Spacen Jasset wrote:
>> I am a little confused, are we going to say that you use POSTFIELDSIZE
>> before setting the data? That won't be backwards compatible with old apps
>> since the null bytes will get in the way... Or are you going to
>> revert/change the code to not make a copy?
>
> Forcing users to set the size first would be the long-term solution. In
> the interim, I'm suggesting first strduping the data as is presently done
> when the CURLOPT_POSTFIELDS comes in, then copying it again when the size
> comes in the size is different from what we copied. In the case of a
> normal C string, the size will be the same and the second copy won't
> happen.
>
>> As far as I could see there was no possible fix to restore compatability
>> without reverting(or changing) the code for CURLOPT_POSTFIELDS back to how
>> it used to work -- not copying the data. -- can't even add a var_args
>> optional parameter becuase it's presence can't be detected.
>
> The rest of libcurl assumes that the data will be copied and must later
> be freed, so the data needs to be copied at some point to maintain
> consistency within libcurl.
>
>> NB - I don't personally mind what happens but it may break other
>> applications that use libcurl.
>
> The proposed heuristic will be completely compatible with pre-7.17.0
> programs. The only difference will be for programs written for 7.17.0
> that assume the copy will take place early and that are sending binary
> postfields, but they're broken now anyway, so this difference in behaviour
> for them (late copy) is irrelevant.
>
>> I am willing to sumbit a patch if you tell me what you would like done (and
>> it's not loads of code!)
>
> It will probably end up being one or two dozen new lines of code. I'll
> let you tackle it unless you say otherwise.
>
>>>> Dan
Ok yes I see now. That's a good idea. There is the slight possibility
that someone will set the post data, free their buffer, and then set the
size, but that is unlikely isn't it. I'll have a go at implementing it
when I am at work tomorrow.

This fix will require the buffer address to be stored somewhere for
later when the size is set, can this go in the CURL structure? It won't
break the multi curl api will it? I must confess I've not looked at that
  api yet.
Received on 2007-10-12