On 22. 7. 25 11:08, Graham Leggett wrote:
On 22 Jul 2025, at 08:23, Daniel Sahlberg<daniel.l.sahlb...@gmail.com>
wrote:
I like the idea of having a sub_status. It might not make much sense to
a
random user, but for debugging purposes it might be useful. Of course it
would be nice to match any subsystem error to proper SERF errors, but
maybe
it doesn't make sense to replicate EVERY error code that could happen.
Maybe it is enough to know there was an error in loading an SSL
certificate
and we can then look up the sub_status in OpenSSL's error code. (We do
this
at $dayjob, our system vendor is returning an error code for "database
error" and the subcode can then be referenced in the database vendor's
error code listing).
In APR-util we return the underlying code, and the underlying string
that matches that code, generated by the underlying library.
The cost of obscuring that underlying error string is immense. Instead
of instantly knowing the reason for the failure, in my case I contacted a
vendor, who then gave a long list of possible reasons for the problem (but
not the actual reason), which was impossible to diagnose without a
debugger. We need to have the most specific error easily accessible to the
end user, so the vendor gives exactly one answer.
https://github.com/apache/apr/blob/trunk/include/apu_errno.h#L418
I tried to follow the code and I can't figure out if there is a place
where
we can store the callback function pointer, except in the
serf_ssl_context_t, just like it is done right now.
This was the problem I had, there was nowhere else to put the callback.
In httpd there is a clear hierarchy, if you have a request_rec in your
hand, you can access the conn_rec above, the server_rec, and so on. There
does not appear to be the same in serf.
Serf has a clear hierarchy, too: context -> connection -> request/response.
serf_ssl_context_t represents a single SSL connection, but that
structure contains no parent reference to the connection itself.
I'm assuming this is reasonably straightforward to fix?
We should add a link back to the parent serf_connection_t (which already
links back to the serf_context_t). The error struct should have pointers
to all three, context, connection and request (when available).
The callback should be registered on the context, as that's the unit of
thread isolation in Serf -- you must not use the same context
simultaneously from different threads, so we know that any callbacks are
triggered synchronously with serf_context_run() or similar.
The only problem is that error info may live longer than those objects,
so users MUST NOT stash those pointers "for later". We could solve that
by careful use of pool cleanups, but I'd prefer to make the
documentation extremely clear about those limitations.
-- Brane
