> > curl_easy_cleanup + curl_easy_init shouldn't behave differently than
> > curl_easy_reset, but the former destroy the Digest state and the
> > latter keeps it
>
> This is documented behavior! curl_easy_reset() keeps state but resets all
> user-settable options back to default. curl_easy_init() of course has no state
> at all.
>
> I'm not sure I see the benefit in also throwing away the state in
> curl_easy_reset().
>
> It is important to remember that libcurl works with _transfers_, not single
> connections and not single requests. The easy handle is an association to
> that transfer and while you can reset the options of the transfer, it still is a
> handle to a transfer or state generated from the previous one. If you close
> the handle, there's no association left to any previous transfer. Then there's
> only connections remaining and connections only have a subset of the state
> info.
>
> I think you need to motivate this better than just operation A should be the
> same as operation B if you think we should change it.

This is not what the documentation on http://curl.haxx.se/libcurl/c/curl_easy_reset.html indicates.
"live connections, the Session ID cache, the DNS cache, the cookies and shares" is a list that imho is completely covered by the use of multi and shared handles, and therefore using new easy handles while keeping multi and shared handles should be the same as curl_easy_reset.

Also I still think it is bad the Proxy-Authorization survives when the connection gets assigned to another easy handle (especially when such behavior breaks connections, like NTLM/Negotiate with MS proxies).

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-23