cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] Fix for intermittent upload failure

From: David Warman <>
Date: Tue, 15 Apr 2014 11:38:46 +0100

On Mon, Apr 14, 2014, at 10:54 PM, Daniel Stenberg wrote:
> On Fri, 11 Apr 2014, David Warman wrote:
> > I ran into an issue where SSL based uploads were failing sometimes. I
> > eventually traced this to a problem with EAGAIN near the start of the
> > transfer, before any data had been sent. This only happened to me with SSL,
> > although it may be possible under other conditions.
> Thanks a lot for helping us improve libcurl. A question though on your patch:
> You say in the commit message:
> "If this module doesn't know the final upload size, data->set.infilesize may
> be zero."
> ...but that's not true! Internally it is set to -1 by default and I just
> checked the man page and it says -1 should be used to "unset" the value.

Ah. This was originally discovered in 7.29(ish), before the man page made
that explicit.

Absent that clarification, it seemed permissible to send zero to indicate
unknown. On reflection, it's not clear why there would need to be a
distinction between "unknown" and "unset", but I had previously assumed
that was the purpose of the -1 initializer (I had noticed the initial

The caller happens to use size == 0 for unknown and sets INFILESIZE to
whatever size it has unconditionally (not hard to change, now it is
clearly necessary).
> I'm asking since the rest of the patch seems to build on that condition and I
> want to understand that condition better first!

Yes, it is based on the assumption that it is legitimate to set INFILESIZE=0
(or rather that this is an acceptable way of indicating an unknown size).

I've only just pulled 7.36 and hadn't spotted the documentation update.
As it happens, the original client code has worked for several years
(before my time working on it, and the start of our git repository),
and only showed an issue when SSL uploading was enabled. So it wasn't
immediately obvious that it wasn't using the API correctly.

BTW, the new PROXYHEADER feature is good news. I have an example of
exactly the problem that it fixes (another thing that has come to light
after switching to SSL).


List admin:
Received on 2014-04-15