One other suggestion on solving this issue generally... I got another
note from the MS engineer. He thinks that the cleanest way to deal with
this is to use chunked transfer-encoding. This way, during the
negotiation of the security, libcurl can tell the server to move on to
the next request simply by sending a zero-length chunk (which according
to the RFC specifies the END of the chunk) if the server returns a 401
status, and if it returns a 100-continue then you can just send the
data, with transfer-encoding as chunked.

I did try turning on te-chunked and it didn't work ootb, but I think
the only reason it didn't was that the "zero-length chunk" isn't sent
if !authdone to "reset" the server and prepare it for another HTTP
request.

I will play more with this tonight. In any case, I think this could
turn out to be the cleanest solution, as we could "force" te-chunked
during the negotiation process and the "revert" to Content-Length if
desired for the final request. Otherwise, we'll have to fix BOTH cases.
Right?

Thoughts?

Alan
Received on 2004-03-26