Hello,

I reproduced a problem with current Curl 7.38.0 and NEGOTIATE Proxy
Authentication in conjunction with a MS TMG 2010 Proxy. Curl is
built with the Windows Schannel-backend.

I'm using the Curl-Multi-API. The Proxy-Authentication does work fine so
far and after the request completed I delete the easy-handle via
curl_easy_cleanup. Right after that I issue another request to the same
server and creating a new easy- handle (witch the same multi-handle) for
that.
Proxy-Authentication works again and everything seems to work. However the
underlying TCP-connection is not reused properly. Instead a new
TCP-connection is opened and a new negotiation is started all over (but
works). (BTW I'm no using https just plain http with mixed GET and POST!)

When I use the exact same code, but instead of deleting the easy-handle
after use and instead put it into a reuse-list and reset it via
curl_easy_reset the TCP-connections are reused and everything still works
fine. I assumed that curl_easy_reset should do pretty much the same as
deleting the easy-handle and creating a new one. Is my observation a bug
or defined behavior?

I can only observe that behavior with NEGOTIATE in conjunction with an MS
TMG 2010 Proxy. When using e.g. DIGEST-Authentication with a Squid-Proxy
it works as expected and reuses the TCP-connection even if I create a new
easy-handle for every request.

After I looked into the code I think I can see the source of the problem:

When using the Mulit-API the connection of the easy-handle is held in the
multi-handle. But the 'struct UrlState' is still bound to the easy-handle.
Part of that struct is 'struct auth authproxy' which holds auth details for
the proxy. In my case it holds the picked authentication method for that
proxy. Even after I reset the easy-handle it still holds the right 'value
struct auth.picked'. When I create a new easy-handle it has to negotiate
the right authentication method with the proxy again and because of that
the proxy closes the connection.

Is this wanted behavior? I think that information should be stored within
the connection which will be stored within the multi-handle.

This behavior is a pretty big performance hit for my application. The
workaround to reuse easy-handles works for me right now, but I don't think
that's how it's supposed to be.

Regards,

Christian

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