On 2. 1. 26 17:07, Daniel Sahlberg wrote:
Den tors 1 jan. 2026 kl 19:53 skrev Branko Čibej<[email protected]>:
On 1. 1. 26 19:45,[email protected] wrote:
Author: brane
Date: Thu Jan 1 18:45:34 2026
New Revision: 1931047
Log:
Added error callback infrastructure.
Discuss...
More seriously: this is only the first step. It removes the
ssl-context-specific error callback and adds a layered tree of callbacks
instead. For now, the SSL error will still go to the global level.
The next step is to revise the SSL functions that log errors and change
their callers to provide an error reporting context.
I hope the design is clear enough from the comments in serf.h,
serf_private.h and src/error_callbacks.c.
Suggestions for improvement welcome. If we decide that this is the right
way forward, I'll continue with he SSL code update and add some tests to
verify that the errors get propagated correctly.
-- Brane
Just asking so I understand this correctly.
In the previous implementation there was a callback (and baton) associated
with the serf_ssl_context_t. Now there is a single static global callback.
Which can be replaced by the user.
If I understand this correctly: Is there any chance/risk that an
application is creating multiple serf_ssl_context_t's where it would be
beneficial to set a separate callback (or more likely baton) for each
context?
This is an intermediate state. I intend to add context-specific
callbacks, but in a way that integrates as well as possible with the
"non-SSL" callbacks, with the global callback being a fallback when no
other context is available. For example, there was one case in the SSL
code where errors were simply silenced due to the lack of an available
callback context. This is no longer the case now.
-- Brane
