Re: libcurl misses end of request data before reading response (patch)
Date: Sun, 7 Jun 2015 23:55:19 +0200 (CEST)
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
- TEXT/x-diff attachment: 0001-urldata-store-POST-size-in-state.infilesize-too.patch