On 04/06/15 23:26, Daniel Stenberg wrote:
No, the server sends the error before the full request has been sent.
That's perfectly legitimate for a server to do.
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.
In other words there is a mismatch of protocol states between the server
(or the wire, seen with wireshark) and curl.
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.
The other way to let curl detect that all bytes have been delivered, is
to set the CURLOPT_INFILESIZE, since then curl counts the written bytes
and therefore does not have to rely on the 0 return code of the
readfunction.
For us it is a Problem because we have to proxy NTLM connections, where
401 responses are part of the handshake that have to be on the same TCP
connection.
cheers, Frank
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
