From: Joe Mason
>> From: curl-library-bounces_at_cool.haxx.se
>> [curl-library-bounces_at_cool.haxx.se] on behalf of Ellié Computing Open
>> Source Program [opensource_at_elliecomputing.com]
>> 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
Received on 2012-07-30