On Thu, 9 Oct 2014, Christian Hägele wrote:

> 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?

Connection-wise it really shouldn't be any difference and in your scenario it
sounds like a bug. It feels like there's state dependent stuff in the easy
handle that makes a difference here.

> 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.

An easy handle owns a whole "transfer". A transfer is lots of state and
possibly many (serial) connections. HTTP authentication is not normally
associated with a specific connection. "Normally", because NTLM is.

> 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.

Proxy auth is a perfect example of state that survives single connections. You
can do a request on connection 1, get a 407 back that closes the connection.
The next auth step with the proxy would then use connection 2 and send the
correct header. It could then even close that connection and make a third etc
and the authentication would just carry on, independently.

When the easy handle is removed, the state for the auth and more is removed
and left is only the connection. The connection should or at least could still
be re-used fine assuming it is left in a known and fine state.

NTLM makes this dance a lot harder since for NTLM the state _is_ bound to the
actual connection so it requires some additional conditionals and quirks.

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

Given your description above it certainly at least sounds as if there's still
some problems left in there to sort out and what state and data to put in
which struct isn't always very easy to decide and work out.

> 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.

I think it would help if you could research into exactly why it fails to
re-use the existing connection when you create a new handle.

-- 
  / daniel.haxx.se

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