On Fri, 5 Jun 2015, Frank Meier wrote:

> The Problem is, curl believes that the server replied too early, that it
> replied before all request bytes have been transferred, but this isn't true.
> The last bytes have been sent to the server after the 2nd last call to the
> readfunction, but curl only "knows" that this is the case after calling the
> readfunction another time, which signals the EOF by returning 0. But this
> happens after curl already tries to read the response.

Aha. Thanks for clarifying and sorry for being slow.

As for your first suggestion I agree completely. I do however suggest a
slightly different fix, see attachment. It runs all the tests for me.

If I understand your problem correctly, this will fix the problem as long as
the post size is known right?

> So what I would like to do is signal from the readfunction that the returned
> bytes are the final ones, but since there is no EOF flag in the API, the
> only way I see is to call the readfunction twice in line to assure curls
> "knows" about the EOF before it tries to read the response.

That feels like a bit too much. In all except the last call, that will return
new data and there's another point that needs to handle pausing and I fear
that'll open the gates for lots of problems.

I would rather consider a way to introduce an EOF flag so that a callback can
actually say "here are the final N bytes of data". Like for example allowing a
callback to OR the return value with 0x20000000 and treat that bit as EOF. Of
course that'd break all older libcurls but would be made to work with a
libcurl supporting this! What would you think about that?

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html