Thank you for your answer.
My idea for mitigating the double big POST problem:
as this cannot be avoided, I planned to POST an empty (or very short) payload for first request, just to get the 401 response and server nonce.
Then http_client calls WinHttpSetCredentials() and seek request body stream to 0 to prepare the resend. This time, the idea is to provide the real POST payload stream.
This implies changing content length and body stream (well, changing the stream is not really required, we can provide another content with the same streambuf object ; but I did not succeed in changing content length). This can work only if digest is not payload dependent, RFC 2069 only.
This may be feasible, however I wonder if this would be applicable for Win8 RT ?
[by the way, is the Win7 client implementation usable under a Win8 desktop computer ?]
My idea for mitigating the double big POST problem:
as this cannot be avoided, I planned to POST an empty (or very short) payload for first request, just to get the 401 response and server nonce.
Then http_client calls WinHttpSetCredentials() and seek request body stream to 0 to prepare the resend. This time, the idea is to provide the real POST payload stream.
This implies changing content length and body stream (well, changing the stream is not really required, we can provide another content with the same streambuf object ; but I did not succeed in changing content length). This can work only if digest is not payload dependent, RFC 2069 only.
This may be feasible, however I wonder if this would be applicable for Win8 RT ?
[by the way, is the Win7 client implementation usable under a Win8 desktop computer ?]