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: Isaac Jurado via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 16 Sep 2021 20:53:58 +0200
On Thu, Sep 16, 2021 at 11:44 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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...
>
> ...
>
> 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.
>
> ...
>
> Isn't using a share handle for cookies the better solution for this?
>
Yes, in-memory handle reuse and share handles solve all cookie problems
within a single process, multiple thread environment.
However, to share cookies across concurrent heterogeneous process, I
understand that share handles are not enough.
In my case, I'm building a toolkit for service integration command line
interfaces so SQLite is an obvious choice to store session/authentication
cookies. But I may be very well sitting in the edge of the Gaussian curve.
While I would never even consider introducing SQLite as a dependency to
solve just this edge case, I was wondering if adding more "extension
points" for cookie management could be an interesting idea from the libcurl
design point of view.
Best regards.
Date: Thu, 16 Sep 2021 20:53:58 +0200
On Thu, Sep 16, 2021 at 11:44 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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...
>
> ...
>
> 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.
>
> ...
>
> Isn't using a share handle for cookies the better solution for this?
>
Yes, in-memory handle reuse and share handles solve all cookie problems
within a single process, multiple thread environment.
However, to share cookies across concurrent heterogeneous process, I
understand that share handles are not enough.
In my case, I'm building a toolkit for service integration command line
interfaces so SQLite is an obvious choice to store session/authentication
cookies. But I may be very well sitting in the edge of the Gaussian curve.
While I would never even consider introducing SQLite as a dependency to
solve just this edge case, I was wondering if adding more "extension
points" for cookie management could be an interesting idea from the libcurl
design point of view.
Best regards.
-- Isaac Jurado "The noblest pleasure is the joy of understanding" Leonardo da Vinci
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-09-16