From: Joe Mason
From: [email protected]
[[email protected]] on behalf of Ellié Computing Open
Source Program [[email protected]]
So, I was thinking of an option such as
“CULROPT_AUTHENTICATION_CONTEXT_GENERATION” (of course naming here is
just a vague idea), it would be 0 by default. It would be tested by the
connection reuse algorithm (can reuse only if values in
‘about-to-be-connected’
and reusable connection are equal). The user code of libcurl would
increment the value each time it knows the user did special things about
authentication information that libcurl cannot be aware of.
Is there another way to do that? or should I propose a patch?
Would the auth callback interface proposed at
http://curl.haxx.se/mail/lib-2012-07/0094.html be useful for this?
Currently (in the >proposed patch) it's only called for HTTP auth, but it
could also be called for SSH key failures.
How would this callback work when the download takes place in a
worker-thread?
These options seems unrelated to me. The problem I have is in particular
when credentials change after a successful first connection, that is false
reuse, not problem connecting (the problem is there, it should refuse the
new request, but libcurl accepts it).
I suppose that's the opposite problem to what you're having - libcurl is
informing the user that the auth parameters which are >supplied to libcurl
must be updated. Your problem is that libcurl does not know about the auth
parameters. But any solution should >not conflict with this interface, and
it would be good to have a similar design to avoid fragmentation.
I don't see any possible conflict, the option would only prevent reuse where
the developer wants to avoid it.
See also the recent discussion on pipelining improvements. I'm starting to
think that it may be useful to expose the concept of >connections to the
embedder and allow them to map curl handles to connections manually is a
good idea after al, so we wouldn't >have to add a new ad-hoc option every
time we find a new criteria for whether or not a connection can be reused.
this option is a bit of the kind "one to rule them all"... because it indeed
cover all the cases where the developer knows connection reuse is
unpractical, its name might be generalized to 'CULROPT_REUSE_GENERATION'...
by the way, when the user increments the value for each request it actually
does the same as FRESH_CONNECT, letting libcurl unused handles.
Regartds
Armel
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
