Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Cookie storage customization?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 16 Sep 2021 11:44:34 +0200 (CEST)
On Wed, 15 Sep 2021, Isaac Jurado via curl-library wrote:
I was curious why optimizing the storage is so important when most of the
cookie handling should be done without storing them on disk at all...
> From what I understand, right now it's not possible to enable
> CURLOPT_FOLLOWLOCATION and be able to manage cookies from "user code" at the
> same time.
That's true. If you want to manage cookies yourself, you should probably just
disable CURLOPT_FOLLOWLOCATION and handle redirects yourself as well.
> Looks like a trade off: if I want to handle cookies but not with libcurl's
> cookie jar, I have to deal with 3xx responses myself too.
The cookie jar (the external file) is only populated by libcurl when you close
the easy handle. Mostly you re-use the handles with the cookies in memory.
> To give more context, I have been prototyping an utility to perform
> authenticated service calls over HTTP. Authentication is OAuth based, but I
> want to maximize session cookie reuse. Therefore, an SQLite based cookie
> store fits very well even in a multiprocess environment (not only
> multithread) thanks to the ACID transactions.
Isn't using a share handle for cookies the better solution for this?
Date: Thu, 16 Sep 2021 11:44:34 +0200 (CEST)
On Wed, 15 Sep 2021, Isaac Jurado via curl-library wrote:
I was curious why optimizing the storage is so important when most of the
cookie handling should be done without storing them on disk at all...
> From what I understand, right now it's not possible to enable
> CURLOPT_FOLLOWLOCATION and be able to manage cookies from "user code" at the
> same time.
That's true. If you want to manage cookies yourself, you should probably just
disable CURLOPT_FOLLOWLOCATION and handle redirects yourself as well.
> Looks like a trade off: if I want to handle cookies but not with libcurl's
> cookie jar, I have to deal with 3xx responses myself too.
The cookie jar (the external file) is only populated by libcurl when you close
the easy handle. Mostly you re-use the handles with the cookies in memory.
> To give more context, I have been prototyping an utility to perform
> authenticated service calls over HTTP. Authentication is OAuth based, but I
> want to maximize session cookie reuse. Therefore, an SQLite based cookie
> store fits very well even in a multiprocess environment (not only
> multithread) thanks to the ACID transactions.
Isn't using a share handle for cookies the better solution for this?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-09-16